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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Neil Williams-2
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?

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?

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.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

David Hampton-2
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


_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

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

David Hampton-2
In reply to this post by Neil Williams-2
On Wed, 2005-07-20 at 14:42 +0100, Neil Williams wrote:
> The HIG only specifies:
> "The secondary text provides the user with some context about the number of
> changes that might be unsaved."

BTW, The HIG also suggests adding a '*' to the window title if there are
unsaved change in the file.

http://developer.gnome.org/projects/gup/hig/2.0/windows-
primary.html#primary-window-titles

Perhaps change notifications should be propagated to a central location.
That way the code can test a single flag instead of scanning all the
objects clases whenever you want to determine if the data file is clean
or dirty.  Makes the test before presenting the save dialog trivial.
Sadly it probably wouldn't allow counting of the number of changes, as
one new transaction would likely generate three or more notifications
(one for the transaction itself and one for each split.)

David


_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
On Wed, Jul 20, 2005 at 12:36:33PM -0400, David Hampton wrote:

> On Wed, 2005-07-20 at 14:42 +0100, Neil Williams wrote:
> > The HIG only specifies:
> > "The secondary text provides the user with some context about the number of
> > changes that might be unsaved."
>
> BTW, The HIG also suggests adding a '*' to the window title if there are
> unsaved change in the file.
>
> http://developer.gnome.org/projects/gup/hig/2.0/windows-
> primary.html#primary-window-titles
>
> Perhaps change notifications should be propagated to a central location.
> That way the code can test a single flag instead of scanning all the
> objects clases whenever you want to determine if the data file is clean
> or dirty.  Makes the test before presenting the save dialog trivial.
> Sadly it probably wouldn't allow counting of the number of changes, as
> one new transaction would likely generate three or more notifications
> (one for the transaction itself and one for each split.)

That reminds me of a question I've had.  ISTM, there's some vision of
"dirtiness" propagating from Instance to Collection.  However, I think
it would make sense if dirtiness propagated up the containment
hierarchy.  E.g. User dirties a Split, which dirties the split's
Transaction, and Account, which dirties the account's Group, which
dirties the Book.  Now, a check for the need to save can just check
the book.  And, the code that commits changes and clears the dirty
flag could also travserse the tree instead of committing whole
Collections, or searching in a Collection for the single split that was
dirtied.

Incidentally, why does Split not even have a dirty flag?  What design
decision governs whether a core engine object should derive from
Instance or Entity?

-chris

>
> David
>
>
> _______________________________________________
> gnucash-patches mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches
_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
In reply to this post by David Hampton-2
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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches
_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

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

David Hampton-2
On Wed, 2005-07-20 at 15:16 -0400, Chris Shoemaker wrote:

> We're already basically lying to the user about what he's done to his
> data,

Other that the bug that opening a register marks the book as changed, do
you have other examples?

David


_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
On Wed, Jul 20, 2005 at 03:46:49PM -0400, David Hampton wrote:
> On Wed, 2005-07-20 at 15:16 -0400, Chris Shoemaker wrote:
>
> > We're already basically lying to the user about what he's done to his
> > data,
>
> Other that the bug that opening a register marks the book as changed, do
> you have other examples?

Nah.  But opening a register is something I do pretty much every time
I open gc, so I'd bet this is behavior almost every user sees.  Oh
well.

-chris

>
> David
>
>
_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches