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

[Chris Shoemaker]

On Wed, Jul 20, 2005 at 10:52:41AM -0400, David Hampton wrote:
> 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.

so have I.

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

I'm really all for the HIG and everything but I think this question of
what to display is moot.  Right now, I'd be happy if it only asked me
to save if I really changed something and closed without asking when I
didn't.  Providing *more* context ("N
minutes/bytes/transactions/whatever") just makes things *worse* when
the test for dirtiness was a false positive anyway.

We're already basically lying to the user about what he's done to his
data, so now we want to include lots of specific details to make our
lie more credible?  :) "No... REALLY... you made changes to your
Checking Account 8 minutes and 32 seconds ago when you opened the
register to look at recent activity.  Do you want to save the changes
or not?!"

Correctness before compliance.

I know this bug is not going to get fixed anytime soon, but let's not
draw any more attention to the fact that we think the usee has changed
their data when they haven't.

-chris

> 
> David
> 
> 
> _______________________________________________
> gnucash-patches mailing list
> gnucash-patches at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches