refreshing the GUI

Dave Peticolas dave@krondo.com
Wed, 29 Nov 2000 11:21:42 -0800


Derek Atkins writes:
> James LewisMoss <jimdres@mindspring.com> 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