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

[Neil Williams]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050720/4ace860e/attachment.bin