On Fri, Jul 22, 2005 at 12:01:56AM +0100, Neil Williams wrote:
> 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.
Ok. as opposed to .... where?
>
> 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.
Ok. Sounds good.
>
> 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.
I'm not sure it's all that complicated. I think split cascades to
account, account cascades to book, and transactions can just cascade
to book, too. With a few other things cascading up to book, I think
David would have what he wants.
>
> You've also switched to only knowing IF there is a dirty split in the
> account,
> not positively identifying WHICH split is dirty.
These are quite related. Knowing the an account does or doesn't
contain a dirty split makes it much easier to find the dirty splits.
>
> The only reason for a tree search is to find WHICH entity is dirty. Setting a
> single gboolean flag is trivial.
That's right, and that flag makes the tree search possible.
-chris
>
> 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/
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
