refreshing the GUI

[Dave Peticolas]

Derek Atkins writes:

> Perhaps this would add up to a LOT of callbacks, having to specify a
> callback for each transaction in each "open" account.  In that sense,
> yes, it is unwieldy.  However, I don't believe that it is "difficult
> to to characterize statically which engine objects need to be
> watched."  I think the above model does a fairly decent job, depending
> on what the GUI has "open".

Perhaps difficult is an overstatement, but I certainly think it is
unwieldy. Also, it's not enough to watch every transaction in the
account, You also need to watch every single account in the system,
since the register contains a drop-down list of accounts.


> > Given the relatively small number of gui components, I decided it would
> > be easier just to have them all called each time.
> 
> Except this doesn't scale to large systems.  If we do get GnuCash to
> the point where it is replacing something like QuickBooks, we might
> have a system with a centralized engine/data storage and distributed
> GUIs where tens or hundreds of users may be accessing data.  You don't
> want to be forcing callbacks to all the components (remember that a
> change in one GUI may affect the data in another GUI) every time a
> change is necessary.  Really, you only want to contact a client if
> something they care about has been changed.

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.

Not that that is a bad thing, but I would like to start small and
simple.


> > That's right, but I envisioned having only one CM.
> 
> Is that one CM for the system, or one CM per GUI?  Imagine a
> distributed system with multiple GUIs attached to the same data store
> engine.

One CM per GUI.


> > Hopefully my previous email explained that well enough?
> 
> Yes, your subsequent mail did explain that successfully, but you may
> have a locking problem in the case of multiple GUIs touching the same
> data.

Probably, but that's just not a problem I'm trying to solve right now.
You're welcome to have a go at it, though.


> I'd like to try to come up with a reasonable multi-user design _now_,
> even if we're only implementing a single-user application.  That way,
> down the road, splitting the GUI, engine, and data store, and adding a
> network protocol between the two, would be easier.

I'd be happy to work with you on such a design, but I need a
single-user solution right now. Is there anything about my proposed
design that will make it difficult to grow it into a mulit-user
solution?

dave