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

David Hampton hampton-gnucash at rainbolthampton.net
Wed Jul 20 10:52:41 EDT 2005


On Wed, 2005-07-20 at 14:42 +0100, Neil Williams wrote:
> 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!)

O.K. I'm confused.  I thought the point of switching to SQL was that the
data was always written through to the database, so that if gnucash
crashed at any point there would be no lost work.

> 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).

How hard is it to keep track of the first time this session you issued
an UPDATE or DELETE command?  I don't need to know what it was, only
when it was.  Isn't the SQL code contained in a small set of files?

> Do other applications interpret "Time Period" in the above manner?

I don't know.  I would love to see "... your 5 changes from the past 1
hour and 30 minutes will be discarded" but I figured that was asking for
too much.

> The HIG only specifies:
> "The secondary text provides the user with some context about the number of 
> changes that might be unsaved."

With a nice big picture showing time in minutes.

> 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.

I don't hear an alternative context proposal here.  What sort of context
do you propose should be provided to users in place of a time?

QOF is already keeps dirty flags for every item in knows about.  How
hard would it be to change the code that marks objects as modified from

  dirty = TRUE

to:

  if (dirty == 0)
    dirty = time();

When you try and close the main gnucash window, QOF already iterates
over the entire set of objects.  It must, in order to determine if a
save dialog is needed.  The best case today is that the first object is
modified and the iteration can bail.  The worst case today is that every
object has to be inspected to discover that it has not been modified.
This is today in every extant version of Gnucash.  The dialog is
different, but the code path to see if the dialog is needed is the same.
In order to provide a time in the context dialog, a boolean test would
be replaced with a test for a non-zero time (still a single instruction)
and then a possible time comparison.  Yes, the entire object tree would
have to be run each time, but is that really a big deal?  Have you
noticed a long delay when quitting gnucash when you haven't changed
anything?  The additional time comparison code would only executed for
each objects that is modified.

> How many people really do leave GnuCash running in the background?

I have on occasion.

> 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.

Agreed, but who cares about the time period since the last save.  I
could care less that I haven't saved in 25 days if there aren't any
changes to the file.  If there are changes to the file, I would like to
know that the change was 42 minutes ago, not wonder what I changed in
the last 25 days.

David




More information about the gnucash-patches mailing list