On Tue, 28 Dec 1999 14:41:01 PST, the world broke into rejoicing as
Dave Peticolas <[EMAIL PROTECTED]> said:
> > Perhaps we need a more distributed-data model? Whenever you have an
> > account 'open', you register a callback with the 'data store'. Then,
> > whenever someone modifies the data store you get called back and
> > notified of the change. Then the GUI can either flag the user in
> > real-time or, if there isn't a conflict, possibly just update itself
> > behind the user.
>
> This would be useful right now in the single-user version.
> We have several independent windows (register, account edit,
> reconcile) that need to get updated whenever an account or
> a related transaction changes. Right now, anything that changes
> engine data has to tell the GUI to update. This means
> that everything that modifies the engine has to know about all
> the different GUI things to update, or else just "update everything."
> This will especially be a problem when we have user-defined scripts.
> An engine callback for updates would solve this nicely.
My first reaction is that this is a place where we need to have
something not unlike CLOS, where methods get told how to update
those things that need to be updated. Slapping that reaction down
quickly, the second reaction is that this may imply a need for an
OO engine. Slapping THAT reaction down quickly...
I was reviewing the contents of /usr/include/glib.h over the holidays to
see what interesting data structure abstractions GLIB (which underlies
GTK) provides.
It's got some "callback" abilities that might be worth reviewing.
Actually, there's rather a lot of stuff there that's worth considering
for use in various places:
a) typedefs for fixed-size objects, such as gint32, gint64
b) wrappers for memory allocation
c) macros for error handling (possibly less powerful than nana, but
if it's ubiquitous, that may still win the day...)
d) list and tree manipulation functions (that might sometimes be
better done on the Scheme side...)
e) in-memory hash tables (although I think I'd rather go with
DB-lib, and get the ability to push data out to disk as needed)
f) a cache manager that I don't fully understand the use for
g) A set of "hook" functions that look a whole lot like the "callbacks"
that you're suggesting.
This would *have* to be done with some careful error checking in
order to ensure that the program doesn't crash due to a minor error...
h) Lexical scanner functions (useful for parsing input)
i) Auto-completion function
This is interesting; you'd insert, for instance, all of the
account names, and then call this with field input when someone
hits "TAB," and it'll try to complete the field.
j) A whole bunch of date calculation functions that might go a long ways
towards providing simple representations of the date parsing questions
that have been discussed of late
There's lots of stuff in this that need not be replicated...
--
CANNOT CREATE INFERIOR (MAYBE SYSTEM FULL?)
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
