On Thursday 21 July 2005 11:09 pm, Chris Shoemaker wrote: > David wants to put a '*' in the window title when the book is dirty. > No problem, query all the collections' dirty flag. Now, say we wanted > to extend the HIG usage to the sub windows. > > We want an account window's title to have '*' is the account is dirty. > Of course, what we actually mean is "does the account contain any > dirty splits?" You may think this can be handled completely by CM > events, but perhaps not. Consider this scenario:
> User opens an Account and adds a Trans with two splits.
> Theoretically, we could catch a CM event here and mark that account
> with a '*'. But, the the user jumps to the other Account in the
> Transaction. This window wasn't around with the dirtying was done, so
> it couldn't catch any events. But, it is dirty, so we'd want to mark
> it with a '*'.
>
> How do we dicover that it contains a dirty split? Either we have to
> search through *every* split in the Collection, seeing if it's in our
> account and is dirty, OR, we just check our Account's "contains
> something dirty" flag. Big difference.
This clearly illustrates the nature of the search: It is an OBJECT issue and
it needs to be done in the objects.
There is no harm in the dirty flag being set in the s->parent and passing that
back to the trans->parent (although this isn't currently part of how a Trans
is handled and there is no trans->parent). What cannot be done is for the
engine to follow that trail backwards because it cannot know that the Split
is a child of Trans. It's just another parameter of an object that happens to
have a name string consisting of "S""p""l""i" and "t" ("\0"). The engine has
no concept of what a Split actually IS - it's just an object of a specific
type with a set of pre-determined parameters.
What you describe above is an upward cascade which is already part of the
dirty flag setup and can easily be added to the *objects*. It has no part in
the marking of the QofCollection as dirty.
The Split can set the dirty flag in it's parent account (and does already) as
this pointer is part of the Split struct. The Trans, in contrast, knows
nothing about the parent account directly - it is currently notified via the
event mechanism after a call from the Split. So the tree doesn't even exist
in the source code as we conceptualise it. The Account cannot call the Trans
directly, it would have to call the Split which would call instead.
Rather than: Account -> Trans -> Split
we have: Split -> Account, Split -> Trans.
From the top:
Trans -> list of Splits in the Trans
Account -> list of Splits in the account.
So the Account can only iterate over all it's splits and the Trans can only
iterate over all it's splits. Neither can identify a single split without
iteration. The hierarchy is not symmetrical neither is does it accord with
the tree model.
You've also switched to only knowing IF there is a dirty split in the account,
not positively identifying WHICH split is dirty.
The only reason for a tree search is to find WHICH entity is dirty. Setting a
single gboolean flag is trivial.
Try this in ASCII / Fixed font display:
Split
|
Trans------------Account
| |
GList of Splits GList of Splits
in this Trans in this Account
Account
|
GList of Splits
|
g_list_foreach
|
Split
|
Trans
Trans
|
GList of Splits
|
g_list_foreach
|
Split
|
Account
That's how the source code implements the "tree".
(events notwithstanding.)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp620CiFfe9S.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
