Derek Atkins writes:
> James LewisMoss <[EMAIL PROTECTED]> writes:
>
> > So a change to data occurs. The engine has a registered listener in
> > the GUI Component Manager that it calls to say something has changed.
> > What happens then?
>
> I suspect that the GUI Component Manager then calls all the components
> that registered a callback for that particular object.
Yes, except that components don't register callbacks for particular
objects. When a refresh cycle occurs, every registered component
gets a callback with a hash table describing the changes. In general,
it's difficult to characterize statically which engine objects need
to be watched.
For example, a register in multi-line mode needs to change if any
transaction which is a parent of one of it's splits is changed, and if
any account which one of its splits is linked to changes.
Each time a split is added to the account, potentially more transactions
and accounts would need to be added to the watch list.
Given the relatively small number of gui components, I decided it would
be easier just to have them all called each time.
> > I'm trying to figure out what the close, find and iteration callbacks
> > are meant to do and who registers with who.
>
> The components register with the Component Manager (CM), which then
> collects the requests and registers with the engine. Basically, you
> can think of it this way (assuming I "get it"): the CM is the
> local-exploder for the GUI callbacks; each 'window' can register for
> the callbacks it wants, but only one set of callbacks get registered
> between the engine and the CM.
>
> When a piece of data changes, the engine calls back to each CM that
> registered for that object, and each CM then calls each component that
> registered. The CM can also allow a single GUI to turn on/off the
> callbacks.
>
> At least, that's how I _think_ he plans to do it.
That's right, but I envisioned having only one CM.
> The hard part, IMHO, is controlling the batching. How do you know
> when a batch is done, or how do you chunk it?
Hopefully my previous email explained that well enough?
dave
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
