refreshing the GUI

Dave Peticolas dave@krondo.com
Fri, 01 Dec 2000 13:32:46 -0800


Derek Atkins writes:
> Dave Peticolas <dave@krondo.com> writes:
> 
> > I see your point, but to achieve real scalability will require much
> > more fine-grained information than just naming engine components you
> > want to watch. Consider that any time an account's name is changed,
> > every register everywhere needs to be updated. So, you have to
> > distinguish between changing an account's name, and changing say,
> > account notes, if you want to avoid excessive refreshes.
> 
> I believe that at some point you need to let the GUI component make
> the decision that an event can be ignored.  Sure, it can get an event
> callback saying that the account notes changed, but it can see that
> it's the notes that changed and just store the new information rather
> than doing any kind of UI refresh.  That's just data refresh (which
> should happen anyways).
> 
> I think there really needs to be a firm line (somewhere) between data
> refresh and UI refresh.  Your particular example (account name vs.
> account notes) is exactly why this differentiation needs to be made.
> The question is, should this differentiation be made in the engine, in
> the CM, or in the components themselves?
> 
> > Not that that is a bad thing, but I would like to start small and
> > simple.
> 
> Agreed.  I'd like the architecture and design to be scalable, but the
> original implementation can certainly be limited in scope :)

I think the 'second pass' design addresses scalability to the point that
is practical currently. It allows components to tell the CM they are
watching specific engine objects. Filtering refreshes will be done in
the CM, for now.

For now, I'd like to keep the engine API & implementation as simple
as possible, since we don't have a multi-user gnucash with which to
experiment with different, more sophisticated designs.

dave