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

classic Classic list List threaded Threaded
76 messages Options
1234
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.

Derek Atkins
In reply to this post by Neil Williams-2
Neil Williams <[hidden email]> 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.

> 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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Andrew Sackville-West


Derek Atkins wrote:
> << munch>>

>>
>>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".  :-/
>
<<snip>>

FWIW, mine is up all the time. literally. I am in the habit of saving
constantly... everytime I get back to the main accounts tab, I now
automatically click on save as data loss for me can be catastrophic (I
have over 1400 transactions and 200+ accounts so far this year) what
with payrolls and all that jazz.  sorry, rambling. Mine is always
running. I go lurk now.

A

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

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

Dan Widyono
In reply to this post by Derek Atkins
> > How many people really do leave GnuCash running in the background?
>
> Lots!

Yeah.  I do.  :)

Dan W.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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.

Derek Atkins
In reply to this post by David Hampton-2
David Hampton <[hidden email]> writes:

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

You're not confused.  That is the point of moving the SQL.  Neil
was just pointing out that the SQL code can do what you're asking
fairly easily.

[snip]

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

I think something like this would work fine.  We really should have
a single interface that we can call to mark an object/instance as
dirty.  That way we can do it in one way and inherit changes, so we
don't need to reimplement it in each object.

This might best go hand-in-hand with an update to the event system.
In particular I want to add more events so we can differentiate
between an account being modified and a new transaction entering an
account (for example).

-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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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
In reply to this post by David Hampton-2
On Wednesday 20 July 2005 3:52 pm, David Hampton wrote:
> 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 SQL backend has a cache capability - with remote backends, e.g. network or
SQL, this would load only enough data to make the book actually usable; it
would not cause *all* of the data to be loaded.

last_update is used for comparing the isntance version in local memory to that
in the remote server.

It's the wrong flag to use for what you want.

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

QOF does not support either UPDATE or DELETE (yet). It's only recently that
I've added INSERT. All editing is done via calls direct to the object - you
edit an Account and the dialog calls a function in Account.c not qofquery.c -
there is no central tally of dynamic data, only the static object
definitions.

When I use param_setfcn, it is up to the relevant function in the *object* to
set any dirty flags or do any other work it needs to do. QOF merely passes
the correct data to the correct function of that instance. It neither cares
nor understands about the object itself.

Also the session has no direct knowledge of changes within the book - it's
just the connection between the book and the filesystem. QofSession doesn't
particularly care if the data is dirty, it'll save it anyway.

Editing an Account sets that instance as dirty. The book doesn't know anything
about saving. Its just that whenever data is modified, the 'dirty' flag is
usually set. This is detected using qof_object_is_dirty which iterates
through each class and each collection for that class. i.e. it is
retrospective. QOF knows nothing about changes until it is asked. The reason
it's so fast currently is that most QOF objects don't *have* an 'is_dirty'
prototype in their object definitions and hence aren't checked to see if they
are dirty (unless the collection is marked as dirty in the Scheme code
somewhere).

As Derek pointed out, the dirty check is by class, not by instance and not
every instance can either set or detect the dirty flag of the collection.
(Unless this is handled in the Scheme).

This is another hurdle I need to clear for the CLI. I'll be looking at tying
this together so that maybe objects no longer call obj->inst.dirty = TRUE
directly but instead call qof_instance_make_dirty((QofInstance*) obj) which
in turn can check that the QofCollection is also marked as dirty. If I get
time to do that, then I could look at setting this as a time and maybe
holding a reference value (to see if this one should update the reference) in
QofBook. I don't know if I'll be able to do that before G2.

To find the oldest change since the last save currently requires iterating
through every *instance*, not just the classes or collections.

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

We can do that - time since the last save. What might not be worth the effort
is time since the last change.

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

Time since last save, not time since last change.

> QOF is already keeps dirty flags for every item in knows about.

Not quite. Each instance *can* keep it's dirty flag but many do not choose to
do so. Those that do, do not always set the dirty flag on their own
collection and most do not set a function prototype that can detect changes
via the book/object interface.

> How
> hard would it be to change the code that marks objects as modified from

In each case, it's the instance that is marked as dirty - not the object
(which would make all instances of that object dirty).

>   dirty = TRUE
>
> to:
>
>   if (dirty == 0)
>     dirty = time();

That's not the hard part. The hard part is then collating those timestamps and
sorting them. Currently, all that matters is that at least *one* instance has
set a dirty flag - it matters not when or who. What you want is a
comprehensive dirty flag that catches edits that may not currently be setting
any dirty flags.

How much of this is currently done in Scheme?

Why are the 'is_dirty' prototypes NULL in almost every object?

Are there situations where dirty instances slip through the net because the
collection is not also set as dirty? (If yes, I'll fix it.)

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

See above. Iterating over the objects (i.e. the collections) is NOT the same
as iterating over every single instance. That is left to the backend during
the actual save. Iterating over every single Split just to find one that's
changed is not part of the dirty check.

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

Objects are far less numerous than instances.

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

Iterating over the entire instance 'tree' would be a big deal, yes.

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

It depends how it works out with the CLI code.

--

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


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

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.

Neil Williams-2
In reply to this post by Derek Atkins
On Wednesday 20 July 2005 6:10 pm, Derek Atkins wrote:
> We really should have
> a single interface that we can call to mark an object/instance as
> dirty.

OK, all I need now is the time to replace every obj->inst.dirty = TRUE with
qof_instance_set_dirty((QofInstance*)obj)
:-(

void qof_instance_set_dirty(QofInstance* inst)
{
        QofBook *book;
        QofCollection *coll;
        QofEntity *ent;

        inst->dirty = TRUE;
        ent = inst->entity;
        book = qof_instance_get_book(inst);
        coll = qof_book_get_collection(book, ent->e_type);
        qof_collection_mark_dirty(coll);
}

Then replace every is_dirty = NULL with
is_dirty = qof_collection_is_dirty

Yes?
       
I'm not sure about the time handling as yet.

My TODO list is getting ever longer . . . .

> That way we can do it in one way and inherit changes, so we
> don't need to reimplement it in each object.

I think we'd need the is_dirty prototype, no?

--

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


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

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.

Neil Williams-2
On Wednesday 20 July 2005 7:28 pm, Neil Williams wrote:

> OK, all I need now is the time to replace every obj->inst.dirty = TRUE with
> qof_instance_set_dirty((QofInstance*)obj)
>
> :-(
>
> void qof_instance_set_dirty(QofInstance* inst)
> {
> QofBook *book;
> QofCollection *coll;
> QofEntity *ent;
>
> inst->dirty = TRUE;
> ent = inst->entity;
ent = &inst->entity;  /* :-) */

> book = qof_instance_get_book(inst);
> coll = qof_book_get_collection(book, ent->e_type);
> qof_collection_mark_dirty(coll);
> }

That function will be in my next commit (which isn't due particularly soon).

> Then replace every is_dirty = NULL with
> is_dirty = qof_collection_is_dirty

and make_clean = NULL with make_clean = qof_collection_make_clean

When a collection is marked clean, does THAT have to iterate down to every
instance? So far, I've avoided anything that requires iteration over every
single instance for this task. It's only the collection that is actually
monitored for being dirty. It seems pointless to check every instance when
only one instance may have caused the collection to be marked as dirty. It's
very quick to code this in but it could add a noticeable delay on Save.

--

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


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

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.

Chris Shoemaker
In reply to this post by David Hampton-2
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.

Neil Williams-2
In reply to this post by Neil Williams-2
On Wednesday 20 July 2005 7:53 pm, Neil Williams wrote:
> When a collection is marked clean, does THAT have to iterate down to every
> instance?

Ignore that, I'll make it so that if the collection is clean,
qof_instance_is_dirty returns (and sets) FALSE.

...
if(qof_collection_is_dirty(coll)) { return inst->dirty; }
inst->dirty = FALSE;
return FALSE;

i.e. don't shortcircuit things by setting inst->dirty direct!

(As part of the CLI, I'll be reviewing the private headers exported by QOF
soon and qofinstance-p.h will be removed from EXTRA_DIST which should prevent
such shortcuts in the future. qofid-p.h will also be removed.)

--

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


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

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.

Chris Shoemaker
In reply to this post by Derek Atkins
On Wed, Jul 20, 2005 at 10:59:20AM -0400, Derek Atkins wrote:

> Neil Williams <[hidden email]> 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
>        [hidden email]                        PGP key available
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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.

Neil Williams-2
In reply to this post by Chris Shoemaker
On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote:
> That reminds me of a question I've had.  ISTM, there's some vision of
> "dirtiness" propagating from Instance to Collection.

There is now, yes.

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

Why such a tortuous path? Split -> Collection -> Book. Checking the book
automatically checks all collections. The Book won't know WHICH split has
been changed so you gain nothing.

With a backend that only stored dirty instances (e.g. by using a local cache -
SQL), then marking the Trans, Account and Group as dirty is
counter-productive. Those haven't changed, only the Split has changed - it
could make a big difference if the backend is actually a network connection.

These backends could identify which collections are dirty in the book - then
identify which instances are dirty by *only* having to iterate over a those
collections, instead of all collections and thereby all instances. In your
example, the backend would only have to iterate over the Splits, not the
entire book. If you make Group dirty everytime a Split is changed, you lose
all ability to identify *which* instances are actually dirty.

> Now, a check for the need to save can just check
> the book.

With the new qof_instance_set_dirty() that will be done in one call.

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

Ah now that would be slower. No point, as I see it, traversing the entire tree
- set the collection to clean and all done.

The QofCollection dirty marker is a single boolean for the entire collection,
it does not require iterating through the collection itself, either to set or
to clear.

> Incidentally, why does Split not even have a dirty flag?

I'll be changing that - every object will use qof_collection_is_dirty and
qof_collection_make_clean in their object definitions.

> What design
> decision governs whether a core engine object should derive from
> Instance or Entity?

?? All core structs contain a QofInstance which itself contains a QofEntity.

--

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


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

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.

Chris Shoemaker
On Wed, Jul 20, 2005 at 08:19:40PM +0100, Neil Williams wrote:

> On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote:
> > That reminds me of a question I've had.  ISTM, there's some vision of
> > "dirtiness" propagating from Instance to Collection.
>
> There is now, yes.
>
> > 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.
>
> Why such a tortuous path? Split -> Collection -> Book. Checking the book
> automatically checks all collections. The Book won't know WHICH split has
> been changed so you gain nothing.

Ah, I didn't realize the Collection's dirtiness propagated to the Book.

>
> With a backend that only stored dirty instances (e.g. by using a local cache -
> SQL), then marking the Trans, Account and Group as dirty is
> counter-productive. Those haven't changed, only the Split has changed - it
> could make a big difference if the backend is actually a network connection.

Maybe there needs to be a distiction between "is dirty itself" and
"contains something dirty."  I think this was what Derek meant when he
was talking about supporting a different event for editing an account
than for adding a transaction.  One would dirty the Account, the other
would only indicate that the Account contained a dirty Transaction.

>
> These backends could identify which collections are dirty in the book - then
> identify which instances are dirty by *only* having to iterate over a those
> collections, instead of all collections and thereby all instances. In your
> example, the backend would only have to iterate over the Splits, not the
> entire book. If you make Group dirty everytime a Split is changed, you lose
> all ability to identify *which* instances are actually dirty.
>
> > Now, a check for the need to save can just check
> > the book.
>
> With the new qof_instance_set_dirty() that will be done in one call.
>
> > 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.
>
> Ah now that would be slower. No point, as I see it, traversing the entire tree
> - set the collection to clean and all done.

Not the entire tree, only the dirty portion.  Extreme example: I have
100000 Splits, and edit one of them which happens to be in an Account
with only 5 Transactions.  A tree search would search 1 book and find
1 dirty*, search 75 Accounts and find 1 dirty*, search 5 Transactions
and find 1 dirty*, search 2 splits and find 1 dirty**, and then commit
one split.

 (*) here, I mean "contains something dirty"
 (**) here, I mean "is itself dirty"

>
> The QofCollection dirty marker is a single boolean for the entire collection,
> it does not require iterating through the collection itself, either to set or
> to clear.

Then you either need a linear search through 100000 Splits, or just to
commit all of them because you only know that the Collection is dirty,
not that it contains 1 dirty Split.

>
> > Incidentally, why does Split not even have a dirty flag?
>
> I'll be changing that - every object will use qof_collection_is_dirty and
> qof_collection_make_clean in their object definitions.
>
> > What design
> > decision governs whether a core engine object should derive from
> > Instance or Entity?
>
> ?? All core structs contain a QofInstance which itself contains a QofEntity.

Except for Split, I guess?  (I'm actually not looking at the code, so
I may be misremembering.)

-chris

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



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

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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 Chris Shoemaker
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
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 Chris Shoemaker
On Wed, 2005-07-20 at 15:03 -0400, Chris Shoemaker wrote:

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

It was added in HEAD and pulled into g2.  Derek thinks the blank split
code should be rewritten.  I'm for reverting the change to the
transaction scrubbing code that created the problem.

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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 20:19 +0100, Neil Williams wrote:

> ?? All core structs contain a QofInstance which itself contains a QofEntity.

Did QoF get extended to commodities and prices?

David


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