[Gnucash-changes] Spruce up the delete window dialog to make it more HIG compliant.

[Chris Shoemaker]

On Wed, Jul 20, 2005 at 10:59:20AM -0400, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> 
> > On Tuesday 19 July 2005 9:04 pm, David Hampton wrote:
> >> +  /*
> >> +   * *** THIS DIALOG IS NOT HIG COMPLIANT. ***
> >> +   *
> >> +   * According to the HIG, the secondary context should include
> >> +   * context about the number of changes that will be lost (either in
> >> +   * time or a count).  While it is possible to simply provide the
> >> +   * time since the last save, that doesn't appear too usefule.  If
> >> +   * the user has had Gnucash open for hours in the background, but
> >> +   * only made a change in the last few minutes, then telling them
> >> +   * they will lose hours work of work is wring.  The QOF code needs
> >> +   * to be modified to provide better timing information.  The best
> >> +   * case scenario would be if QOF could provide a timestamp of the
> >> +   * oldest unsaved change.
> >> +   */
> >
> > The SQL backend uses qof_instance_get_last_update but this dialog would 
> > require iterating over every instance in the book, one type at a time prior 
> > to displaying the dialog, then sorting the timespecs (and this when the user 
> > is waiting for the app to close!)
> >
> > The alternative method would involve keeping tabs on all instances and sorting 
> > the various update times but then that structure would need to be stored 
> > outside the library anyway (couldn't be a static).
> >
> > Do other applications interpret "Time Period" in the above manner?
> 
> I think that iterating through all the instances in the book is way
> too much overhead.  Iterating through each class would be okay, as there
> are a limited number of classes.
> 
> However, I think that just saying something like "You last saved your
> data at [timestamp].  If you quit now without saving then you will
> lose all changes you've made in [delta]."  Obviously this is only
> required if changes have been made.  This requires fixing the register
> code so that opening the register does not automagically dirty the
> book.

I've looked at this pretty closely.  This is not easy to change.
Opening the register creates many cascades of events which dirty lots
of objects.  In particular, this is due to the handling of the blank
split/trans.  Showing a blank split/trans actually involves modifying
the financial objects.  Avoiding this is one of the chief design goals
of my register re-write.

Incidentally, is this behavior specific to g2?  I've never noticed it
in 1.x, but I imagine the register code hasn't changed much.

-chris

> 
> > The HIG only specifies:
> > "The secondary text provides the user with some context about the number of 
> > changes that might be unsaved."
> >
> > IMHO, "some context" does not mean "number of seconds since the last change, 
> > anywhere in a 2Mb book". The iterations themselves could delay the display of 
> > the dialog. I don't see how this is a job for the QOF library.
> >
> > How many people really do leave GnuCash running in the background?
> 
> Lots!  Don't make assumptions about how people use the app; you'll
> always be wrong.  Whenever you find yourself thinking "user's wont do
> that" you'll undoubtedly get hit with tons of bug reports when users
> "do that".  :-/
> 
> > http://developer.gnome.org/projects/gup/hig/1.0/windows.html#alerts-confirmation
> >
> > The example itself only shows a simple time period, no hint that this has to 
> > be the time period since the last modification or the last save.
> 
> -derek
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel