Re: Questions about the Backend Interface
Thanks. More responses inline... Dave Peticolas <[EMAIL PROTECTED]> writes: > The rollback is supposed to undo any changes which have been made > since TransBeginEdit and restore the transaction to its original > state. Restoring the data is actually done by the engine, so I'm > presuming that backends would implement this by releasing any locks, > etc. that were created by trans_begin_edit. Presumably, single user > backends have no need to implement this callback. Linas will know > more about this, though. That's what I thought. Since all the edits are done in the engine cache, the backend really just needs to unlock the structure. Is there any reason that we don't have a rollback on an account edit, too? > > 3) The 'sync()' operation seems to be an extremely heavy > >operation, especially for a networked backend. > > The operation is probably going to change. It is invoked by both > 'Save' and 'Save As' functionality. But backends which implement > the 'fine-grained' backend calls (like the sql backend) don't > need to do anything during a 'save'. So the call will probably > be split into two calls for that reason. Fair enough... Although I'm not exactly sure how 'save-as' will work for a fine-grained backed. For those backends the current file would always be up-to-date with the engine cache, so you're right, save would do nothing, and save-as would just copy the data elsewhere. However 'save-as' would never leave the original file as it was before any edits were made. I thought of another issue.. There doesn't appear to be a way for the backend to notify the engine that and account or transaction was deleted out from under it. This is probably related to question #2 below. Unless I'm missing something, during a sync operation there is no way to tell the difference between a "new" object or an object that was deleted in the backend. Thanks, > dave -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: > > Thanks. > > More responses inline... > > Dave Peticolas <[EMAIL PROTECTED]> writes: > > > The rollback is supposed to undo any changes which have been made > > since TransBeginEdit and restore the transaction to its original > > state. Restoring the data is actually done by the engine, so I'm > > presuming that backends would implement this by releasing any locks, > > etc. that were created by trans_begin_edit. Presumably, single user > > backends have no need to implement this callback. Linas will know > > more about this, though. Rollback for transactions in the multi-user case is sort of broken. If the data in the database is newer than whats in the engine, then any proposed updates from the user must not only be rejected, but the newer data from the database must also be pulled in. This isn't done yet. One other little problem: 'rollback' is used in two, unrelated ways. 1) by the gui, to implement 'undo' 2) by the engine, (when the above paragraph gets fixed). Some work needs to be done to disambiguate the above. > That's what I thought. Since all the edits are done in the engine > cache, the backend really just needs to unlock the structure. Is > there any reason that we don't have a rollback on an account edit, > too? Not yet implemented; see above. > > > 3) The 'sync()' operation seems to be an extremely heavy > > >operation, especially for a networked backend. > > > > The operation is probably going to change. It is invoked by both > > 'Save' and 'Save As' functionality. But backends which implement > > the 'fine-grained' backend calls (like the sql backend) don't > > need to do anything during a 'save'. So the call will probably > > be split into two calls for that reason. > > Fair enough... Although I'm not exactly sure how 'save-as' will work > for a fine-grained backed. As it currently works, its a mass-copy of all data out of the gnucash engine into the named storage location. If the indicated storage location doesn't exist, its created, and all of the engine data is copied into it. If the storage location (i.e. database) does exist, and contains data, then the engine contents are merged into it. >From the engine point of view, the above is the easiest thing to do. However, in some cases, it may not be what the user is expecting. For example: in the (unfinished) multi-user mode, the engine does *not* contain a full copy of the database data; instead, it contains only a subset. A 'save as', if implemented as above, would save only that subset, instead of all of the data. If the user thought 'save as' means the same thing as 'copy', they would be sorely disappointed. I don't currently have an opinion on the 'best' way of dealing with this situation. > I thought of another issue.. There doesn't appear to be a way for the > backend to notify the engine that and account or transaction was > deleted out from under it. Or merely changed, for that matter. At some point, we'll need to work with Dave to fiugre out how to use the event system so that a backend can notify the engine that some other user has modified data. > This is probably related to question #2 > below. Unless I'm missing something, during a sync operation there is > no way to tell the difference between a "new" object or an object that > was deleted in the backend. U, ahhh, ohh... deleted splits are accounted for since we can detect that the number of splits in a transaction has changed. But if the entire transaction was deleted by some other user, then the engine currently would conclude that what it has is something new, not something deleted. I see two ways of fixing this. 1) Keep a master list of all transactions. If a transaction is not in the list, it should be deleted. (since, in theory, there is nno way to create a new transaction wihout putting it on the list). 2) Keep an audit trail of modified & deleted transactions; and check that. I admit, the multi user case, with data caching in the engine, is proving more complex & harder to implement than I anticipated. Where I last left it, account balances were giving me heartaches. --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
How to get a list of all (cached) transactions?
Hi, What's the best way to get a list of all the transactions in an accountgroup, recursively? At least, I'm assuming the 'sync()' Backend callback is expected to act recursively on the children of all accounts, so I need a way to determine all the transactions in all the accounts. It sounds like all the staged traversal code is non-recursive... Is there a documented way to do this? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Dave Peticolas said: > > > I'll answer as best I can. Linas is more familiar with the Backend > code so he will be able to give more information. > > > Derek Atkins writes: > > So, I've been working on implementing an RPC backend, but I've > > got a few questions: > > > > 0) There appears to be no way to allow the backend to callback > >to the client to request a username/password or some other > >authentication. I don't like the "hack" of putting the > >username and password into the URL. > > I think Linas is planning on adding that in for the sql code so the > RPC backend should be able to use the same hook. The dialog has already > been created, it just needs to be added to the Backend infrastructure. Any prefered API? gnc_login(char * username, char * passwd) ? This isn't enough for e.g. kerberos authentication, but maybe enough for now? > > 2) There appears to be no way for the backend to trigger an > >event to the engine/GUI if something happens. For example, > >I'd like the backend (server) to signal to the engine > >(client) that some information changed, or perhaps even > >pushing the changed information. Terminology, as used in gnucash: -- backend: the part of the client that knows how to talk to servers. -- engine: the part of the client that provides a data cache and a uniform API to the GUI. To answer your question: in practice, the backend can 'push' new data into the engine, because it has access to all the pointers & structures. In principle, there is not yet any set policy: is the engine in charge and telling the backend to do its bidding (including optionally handling events that the backend generated?) Or is the backend in charge, mangling engine data as it sees fit? Opinions? ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Thanks for the reply. Comment inline... <[EMAIL PROTECTED]> writes: > Rollback for transactions in the multi-user case is sort of broken. > If the data in the database is newer than whats in the engine, then > any proposed updates from the user must not only be rejected, but the > newer data from the database must also be pulled in. This isn't done > yet. > > One other little problem: 'rollback' is used in two, unrelated ways. > 1) by the gui, to implement 'undo' > 2) by the engine, (when the above paragraph gets fixed). Some work >needs to be done to disambiguate the above. Ok, so the rollback method implementation needs to get a return value from the actual data store (RPC Server in my case) in case the txn changed. This implies the client must send not only the txn guid but also the version number, and the return may include a new transaction. Good thing to know :) > > That's what I thought. Since all the edits are done in the engine > > cache, the backend really just needs to unlock the structure. Is > > there any reason that we don't have a rollback on an account edit, > > too? > > Not yet implemented; see above. So there is plans to have an 'account rollback' method (to rollback edits to an Account*)? > As it currently works, its a mass-copy of all data out of the gnucash > engine into the named storage location. > > If the indicated storage location doesn't exist, its created, and > all of the engine data is copied into it. > > If the storage location (i.e. database) does exist, and contains data, > then the engine contents are merged into it. Hrm. Perhaps certain back-ends might not support a 'save-as', or do all backends need to do it? Indeed, I'm not even convinced that 'save-as' makes any sense in a database or server-based backend. So, perhaps we just shouldn't provide the option for those types of backend? > > From the engine point of view, the above is the easiest thing to do. > However, in some cases, it may not be what the user is expecting. > For example: in the (unfinished) multi-user mode, the engine does > *not* contain a full copy of the database data; instead, it contains > only a subset. A 'save as', if implemented as above, would save only > that subset, instead of all of the data. If the user thought 'save as' > means the same thing as 'copy', they would be sorely disappointed. > I don't currently have an opinion on the 'best' way of dealing with this > situation. Well, I guess it depends on what the user expects, doesn't it? Worse, what might happen depends on what the backend is. I think a 'copy file' might require specific calls to the backend, although how would you 'copy file' from one backend type to another? A large can of worms, I agree. > > I thought of another issue.. There doesn't appear to be a way for the > > backend to notify the engine that and account or transaction was > > deleted out from under it. > > Or merely changed, for that matter. At some point, we'll need to work > with Dave to fiugre out how to use the event system so that a backend > can notify the engine that some other user has modified data. Agreed. Shouldn't be too hard. I just need to know what functions to implement, and the client will just receive them from the server and signal an event to the GUI. > > This is probably related to question #2 > > below. Unless I'm missing something, during a sync operation there is > > no way to tell the difference between a "new" object or an object that > > was deleted in the backend. > > U, ahhh, ohh... deleted splits are accounted for since we can detect > that the number of splits in a transaction has changed. But if the > entire transaction was deleted by some other user, then the engine > currently would conclude that what it has is something new, not > something deleted. :) > I see two ways of fixing this. > 1) Keep a master list of all transactions. If a transaction is not in >the list, it should be deleted. (since, in theory, there is nno way >to create a new transaction wihout putting it on the list). > > 2) Keep an audit trail of modified & deleted transactions; and check >that. The latter is certainly a reasonable option, although both would work. In my case, I'm actually depending on the engine (and another backend) to perform the actual data storage behind the RPC server. > I admit, the multi user case, with data caching in the engine, is > proving more complex & harder to implement than I anticipated. Where I > last left it, account balances were giving me heartaches. I'm just working on 'single-user' but I'm still only dealing with cached transactions. I'm still coding my 'first attempt', so I don't even know how account balances are supposed to work, or what information I need and when I need it. > --linas -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://we
Re: Questions about the Backend Interface
[EMAIL PROTECTED] writes: > Any prefered API? > gnc_login(char * username, char * passwd) ? > This isn't enough for e.g. kerberos authentication, but maybe enough > for now? Good question. I don't have a good answer. Assuming this is the function that the backend calls to ask the user (wouldn't the backend need some gpointer for window data?), I think a better API might be: int gnc_login (char *username, gint32 user_size, char *passwd, gint32 pass_size, gpointer arg) This way the backend can tell the UI: a) how big the username and password buffers are, and b) provide a UI callback arg for windows. Obviously, this would require the UI to register the CB arg, perhaps as a part of the 'book_open()' or 'book_load()' backend methods? > > > 2) There appears to be no way for the backend to trigger an > > >event to the engine/GUI if something happens. For example, > > >I'd like the backend (server) to signal to the engine > > >(client) that some information changed, or perhaps even > > >pushing the changed information. > > Terminology, as used in gnucash: > -- backend: the part of the client that knows how to talk to servers. > -- engine: the part of the client that provides a data cache and a >uniform API to the GUI. > > To answer your question: in practice, the backend can 'push' new data > into the engine, because it has access to all the pointers & structures. Hrm. Then perhaps the best way to 'trigger' an event is to have the server push the new data to the backend, and the backend can then push it into the engine and notify the engine that the data has changed? > In principle, there is not yet any set policy: is the engine in charge > and telling the backend to do its bidding (including optionally handling > events that the backend generated?) Or is the backend in charge, > mangling engine data as it sees fit? There are a number of ways of looking at it. My view is that the engine (data cache) and backend are all one thing, and the UI is a second part of the Gnucash client. Therefore, neither the backend nor the engine are 'in charge'. Either can change data, and when it happens they inform the other half. Obviously this means that when the UI changes data, it calls into the backend, and when the backend changes the cache, it calls into the engine that calls up to the UI. > Opinions? Many approaches. Many choices. I don't know what's the best way. I think there are many ways of doing this that are all reasonable. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: > > Thanks for the reply. Comment inline... > > <[EMAIL PROTECTED]> writes: > > > Rollback for transactions in the multi-user case is sort of broken. > > If the data in the database is newer than whats in the engine, then > > any proposed updates from the user must not only be rejected, but the > > newer data from the database must also be pulled in. This isn't done > > yet. > > > > One other little problem: 'rollback' is used in two, unrelated ways. > > 1) by the gui, to implement 'undo' > > 2) by the engine, (when the above paragraph gets fixed). Some work > >needs to be done to disambiguate the above. > > Ok, so the rollback method implementation needs to get a return value > from the actual data store (RPC Server in my case) in case the txn > changed. This implies the client must send not only the txn guid but > also the version number, and the return may include a new transaction. > Good thing to know :) I think I want to retract some of my comments. By default, when the gui calls xaccTransRollback(), it will merely restore the data that was previously cached in the engine. And should mostly be enough: its highly unlikely that some other user changed the very same transaction, so its a waste of bandwidth to have to double-check with the server. In the event that the server data *did* change, then the 'standard' way in which the server notifies changes should be sufficient, and special 'rollbck' handling isn't really needed ... > So there is plans to have an 'account rollback' method (to rollback > edits to an Account*)? Yes. > Hrm. Perhaps certain back-ends might not support a 'save-as', or do > all backends need to do it? Indeed, I'm not even convinced that > 'save-as' makes any sense in a database or server-based backend. So, > perhaps we just shouldn't provide the option for those types of > backend? Well, there's two ways that its important to support: a) its the only way (currently) of copying data from a prexisting file to a database. Its how one would migrate into sql. b) off-line operation: Say a user builds up a cache of data, saves it to a file, edits it off-line (e.g. while sitting at the airport) and then comes back on-line. The user will then want to 'sync' i.e. copy thier modified data into the server. Scenario b) needs work. What we have is almost right, but both the GUI, and a crisping up of the semantics is needed. > The latter is certainly a reasonable option, although both would work. > In my case, I'm actually depending on the engine (and another backend) > to perform the actual data storage behind the RPC server. Yep, that's what I would have recommended. > > account balances were giving me heartaches. > > even know how account balances are supposed to work, well, if the engine has *all* of the splits in an account, it totals them up to get the running balances. But if it has a subset of all splits, then ... let me leave it at tat . --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
<[EMAIL PROTECTED]> writes: > I think I want to retract some of my comments. By default, when the gui > calls xaccTransRollback(), it will merely restore the data that was > previously cached in the engine. And should mostly be enough: its highly > unlikely that some other user changed the very same transaction, so its > a waste of bandwidth to have to double-check with the server. Ok, so the rollback method is just an 'unlock'. Ok. > well, if the engine has *all* of the splits in an account, it totals > them up to get the running balances. But if it has a subset of all > splits, then ... let me leave it at tat . I see... > --linas -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: How to get a list of all (cached) transactions?
Derek Atkins writes: > Hi, > > What's the best way to get a list of all the transactions in an > accountgroup, recursively? At least, I'm assuming the 'sync()' > Backend callback is expected to act recursively on the children > of all accounts, so I need a way to determine all the transactions > in all the accounts. > > It sounds like all the staged traversal code is non-recursive... > Is there a documented way to do this? Hmm, the docs for xaccGroupForEachTransaction are wrong. It *does* recursively descend the hierarchy. I will fix this. Anyway, xaccGroupForEachTransaction is probably the best way. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: > > > > 2) There appears to be no way for the backend to trigger an > > > >event to the engine/GUI if something happens. For example, > > > >I'd like the backend (server) to signal to the engine > > > >(client) that some information changed, or perhaps even > > > >pushing the changed information. > > > > Terminology, as used in gnucash: > > -- backend: the part of the client that knows how to talk to servers. > > -- engine: the part of the client that provides a data cache and a > >uniform API to the GUI. > > > > To answer your question: in practice, the backend can 'push' new data > > into the engine, because it has access to all the pointers & structures. > > Hrm. Then perhaps the best way to 'trigger' an event is to have the > server push the new data to the backend, and the backend can then push > it into the engine and notify the engine that the data has changed? Yes. Although the last step can be skipped: the backend itself can trigger the event mechanism to tell the gui that something changed (using suspend_events and resume_events in gnc-event.c, I beleive). --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: > > <[EMAIL PROTECTED]> writes: > > > I think I want to retract some of my comments. By default, when the gui > > calls xaccTransRollback(), it will merely restore the data that was > > previously cached in the engine. And should mostly be enough: its highly > > unlikely that some other user changed the very same transaction, so its > > a waste of bandwidth to have to double-check with the server. > > Ok, so the rollback method is just an 'unlock'. Ok. Only if the begin method was a lock. For the postgres backend, its all 'atomic': when the gui calls xaccTransBeginEdit, its a no-op. When it calls xaccTransCommitEdit(), it locks, writes data, unlocks. A deadlock can't happen, since a lock is never held outside the scope of the backend. (i.e. all locks are released before the backend returns to the engine/gui). --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
writes: > It's been rumoured that Derek Atkins said: > > > > > 2) There appears to be no way for the backend to trigger an > > > > >event to the engine/GUI if something happens. For example > , > > > > >I'd like the backend (server) to signal to the engine > > > > >(client) that some information changed, or perhaps even > > > > >pushing the changed information. > > > > > > Terminology, as used in gnucash: > > > -- backend: the part of the client that knows how to talk to servers. > > > -- engine: the part of the client that provides a data cache and a > > >uniform API to the GUI. > > > > > > To answer your question: in practice, the backend can 'push' new data > > > into the engine, because it has access to all the pointers & structures. > > > > Hrm. Then perhaps the best way to 'trigger' an event is to have the > > server push the new data to the backend, and the backend can then push > > it into the engine and notify the engine that the data has changed? > > Yes. Although the last step can be skipped: the backend itself > can trigger the event mechanism to tell the gui that something changed > (using suspend_events and resume_events in gnc-event.c, I beleive). We must be careful here. Presumably the Backend is going to receive information that the engine needs to be updated by some out-of-band mechanism like a signal. Right now, the Backend must not mess with the engine outside of the normal flow of control. Everything outside the engine has been written under the assumption that the engine cannot change outside of the current thread of control. Relaxing that assumption would require a significant amount of work. I think it would be much easier if the Backend informed the engine that it needs to be synchronized with the external source, and then the GUI event loop would poll the engine and, if needed, tell it to synchronize with the external source. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
initial testing with 1.5.3 and it looks very sweet..just wanted to say that and thanks for alot of hard work on this.:) latre lee -=== ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
<[EMAIL PROTECTED]> writes: > > Hrm. Then perhaps the best way to 'trigger' an event is to have the > > server push the new data to the backend, and the backend can then push > > it into the engine and notify the engine that the data has changed? > > Yes. Although the last step can be skipped: the backend itself > can trigger the event mechanism to tell the gui that something changed > (using suspend_events and resume_events in gnc-event.c, I beleive). Ahh, wonderful. Then all I need to do is create an 'update' callback. I wonder if it's safe to perform callbacks on single items, or if I should allow lists of updates to be pushed from the server? > --linas -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: > > <[EMAIL PROTECTED]> writes: > > > > Hrm. Then perhaps the best way to 'trigger' an event is to have the > > > server push the new data to the backend, and the backend can then push > > > it into the engine and notify the engine that the data has changed? > > > > Yes. Although the last step can be skipped: the backend itself > > can trigger the event mechanism to tell the gui that something changed > > (using suspend_events and resume_events in gnc-event.c, I beleive). > > Ahh, wonderful. Then all I need to do is create an 'update' callback. > I wonder if it's safe to perform callbacks on single items, or if I should > allow lists of updates to be pushed from the server? You probably want to batch as much as possible, otherwise the gui will flash and blink every time it tries to refresh itself. --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
writes: > It's been rumoured that Derek Atkins said: > > > > > 2) There appears to be no way for the backend to trigger an > > > > >event to the engine/GUI if something happens. For example > , > > > > >I'd like the backend (server) to signal to the engine > > > > >(client) that some information changed, or perhaps even > > > > >pushing the changed information. > > > > > > Terminology, as used in gnucash: > > > -- backend: the part of the client that knows how to talk to servers. > > > -- engine: the part of the client that provides a data cache and a > > >uniform API to the GUI. > > > > > > To answer your question: in practice, the backend can 'push' new data > > > into the engine, because it has access to all the pointers & structures. > > > > Hrm. Then perhaps the best way to 'trigger' an event is to have the > > server push the new data to the backend, and the backend can then push > > it into the engine and notify the engine that the data has changed? > > Yes. Although the last step can be skipped: the backend itself > can trigger the event mechanism to tell the gui that something changed > (using suspend_events and resume_events in gnc-event.c, I beleive). We must be careful here. Presumably the Backend is going to receive information that the engine needs to be updated by some out-of-band mechanism like a signal. Right now, the Backend must not mess with the engine outside of the normal flow of control. Everything outside the engine has been written under the assumption that the engine cannot change outside of the current thread of control. Relaxing that assumption would require a significant amount of work. I think it would be much easier if the Backend informed the engine that it needs to be synchronized with the external source, and then the GUI event loop would poll the engine and, if needed, tell it to synchronize with the external source. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
<[EMAIL PROTECTED]> writes: > You probably want to batch as much as possible, otherwise the gui will > flash and blink every time it tries to refresh itself. Well, I was only referring to when data changes in the data-store. But I suppose that data there could be updated en-masse (ala sync()) so I should probably support a batched event notification. > --linas -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Dave Peticolas <[EMAIL PROTECTED]> writes: > We must be careful here. Presumably the Backend is going to receive > information that the engine needs to be updated by some out-of-band > mechanism like a signal. Right now, the Backend must not mess with > the engine outside of the normal flow of control. Everything outside > the engine has been written under the assumption that the engine > cannot change outside of the current thread of control. Relaxing > that assumption would require a significant amount of work. > > I think it would be much easier if the Backend informed the engine > that it needs to be synchronized with the external source, and then > the GUI event loop would poll the engine and, if needed, tell it to > synchronize with the external source. This works well for Transactions. I could just have the server send a list of all the 'changed' transactions. The backend can just save that transaction list and signal that there is update work to be done. Then it can request the updated list of transactions from the server. I suppose I could do the same thing with accounts. However I'm going to have to change how I think about it. In particular, I need to change how I cope with account parenting. Currently I'm only transfering complete AccountGroups.. If I'm going to transfer a single account at a time, I'm going to need a way to signal that the parent changed. Unfortunately an AccountGroup doesn't have a GUID, so I really need to grab account->parent->parent->guid to figure out who my parent is (and assume that I'm a top-level account is account->parent->parent is NULL). > dave -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Derek Atkins writes: > Dave Peticolas <[EMAIL PROTECTED]> writes: > > > We must be careful here. Presumably the Backend is going to receive > > information that the engine needs to be updated by some out-of-band > > mechanism like a signal. Right now, the Backend must not mess with > > the engine outside of the normal flow of control. Everything outside > > the engine has been written under the assumption that the engine > > cannot change outside of the current thread of control. Relaxing > > that assumption would require a significant amount of work. > > > > I think it would be much easier if the Backend informed the engine > > that it needs to be synchronized with the external source, and then > > the GUI event loop would poll the engine and, if needed, tell it to > > synchronize with the external source. > > This works well for Transactions. I could just have the server > send a list of all the 'changed' transactions. The backend can just > save that transaction list and signal that there is update work to be > done. Then it can request the updated list of transactions from the > server. > > I suppose I could do the same thing with accounts. However I'm going > to have to change how I think about it. In particular, I need to > change how I cope with account parenting. Currently I'm only > transfering complete AccountGroups.. If I'm going to transfer a > single account at a time, I'm going to need a way to signal that the > parent changed. Unfortunately an AccountGroup doesn't have a GUID, so > I really need to grab account->parent->parent->guid to figure out who > my parent is (and assume that I'm a top-level account is > account->parent->parent is NULL). Yes, that is the case. As long as the change happens in the normal flow of control, the GUI should handle reparenting gracefully. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Dave Peticolas <[EMAIL PROTECTED]> writes: > Yes, that is the case. As long as the change happens in the normal > flow of control, the GUI should handle reparenting gracefully. Ok, then all we need it a flag that I can set (from another thread) that the engine/gui loop checks and calls back into the backend whenever it's set. I presume I can use 'gnc_book_get_group()' to get the top-level group in book? If so, then we just need something like: void gncSetEventFlag (void); and the Backend method can be something like: void (*process_event) (Backend *be); > dave -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Derek Atkins writes: > Dave Peticolas <[EMAIL PROTECTED]> writes: > > > Yes, that is the case. As long as the change happens in the normal > > flow of control, the GUI should handle reparenting gracefully. > > Ok, then all we need it a flag that I can set (from another thread) > that the engine/gui loop checks and calls back into the backend > whenever it's set. > > I presume I can use 'gnc_book_get_group()' to get the top-level group > in book? Yes, correct. > If so, then we just need something like: > void gncSetEventFlag (void); > > and the Backend method can be something like: > void (*process_event) (Backend *be); Ok, I will work on adding this today. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Dave Peticolas <[EMAIL PROTECTED]> writes: > > If so, then we just need something like: > > void gncSetEventFlag (void); > > > > and the Backend method can be something like: > > void (*process_event) (Backend *be); > > Ok, I will work on adding this today. Ok. We should probably also have a'ClearEventFlag()' for when the event(s) get handled. Also, do you plan to make this MT-Safe, or should a multi-threaded backend use a mutex around these functions? I don't really care either way. I'm kind of thinking that the backend might want to handle the locking itself, because it will need to lock the event-staging-area anyways. > dave -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Derek Atkins writes: > Dave Peticolas <[EMAIL PROTECTED]> writes: > > > > If so, then we just need something like: > > > void gncSetEventFlag (void); > > > > > > and the Backend method can be something like: > > > void (*process_event) (Backend *be); > > > > Ok, I will work on adding this today. > > Ok. We should probably also have a'ClearEventFlag()' for when the > event(s) get handled. > > Also, do you plan to make this MT-Safe, or should a multi-threaded > backend use a mutex around these functions? I don't really care > either way. I'm kind of thinking that the backend might want to > handle the locking itself, because it will need to lock the > event-staging-area anyways. How about we make the 'are there events pending' call a part of the backend api as well. So the engine/gui would just ask the backend if there are events and the backend would clear the flag when they are handled. That way, backends which need to implement mutexes can do so and the rest don't need to. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
splash screen
> The splash screen currently in place is just a graphic I grabbed > off our webpage so I would have something to test with (I don't > have any gimp skills). I was thinking that we would eventually > find one that isn't specific to a particular locale, but making > specific ones for specific locales is an interesting idea. I object to this on general application-bloat grounds. Your users will have 99 graphics sitting on their disk that they never see, and only one that they actually use. Unless you can include all the graphics you want in less than, say, 50K, I think the cost outweighs the coolness. I know, disks are cheap, I should go buy a 300 gig disk for $1.37 from my local corner store, but if you have a laptop, for instance, it's not always easy to get a bigger disk. Greg ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Dave Peticolas <[EMAIL PROTECTED]> writes: > How about we make the 'are there events pending' call a part of the > backend api as well. So the engine/gui would just ask the backend if > there are events and the backend would clear the flag when they are > handled. That way, backends which need to implement mutexes can do so > and the rest don't need to. That works. Something like: gboolean (*events_pending) (Backend *be); ?? :) > dave -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: splash screen
Gregory Novak wrote: > > > The splash screen currently in place is just a graphic I grabbed > > off our webpage so I would have something to test with (I don't > > have any gimp skills). I was thinking that we would eventually > > find one that isn't specific to a particular locale, but making > > specific ones for specific locales is an interesting idea. > > I object to this on general application-bloat grounds. Your users will > have 99 graphics sitting on their disk that they never see, and only one > that they actually use. Unless you can include all the graphics you want > in less than, say, 50K, I think the cost outweighs the coolness. > > I know, disks are cheap, I should go buy a 300 gig disk for $1.37 from my > local corner store, but if you have a laptop, for instance, it's not > always easy to get a bigger disk. Hi! With i18n every translation of the online manual gets its own set of screenshot images (so that menu item and so on are in the right language). This is far more than the splash screens in different languages. But I think there is an option to specify which translations get installed. Herbert. -- Herbert Thoma FhG-IIS A, Studio Department Am Weichselgarten3, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/ ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
What is libgal?
Ok, what is libgal? I've been successfully compiling without it for a while, and I don't seem to have it on my system. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: What is libgal?
Derek Atkins writes: > Ok, what is libgal? I've been successfully compiling without > it for a while, and I don't seem to have it on my system. It's used by gtkhtml, or at least by later versions of gtkhtml. What version of gtkhtml are you using? dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: What is libgal?
An old one... :) -derek Dave Peticolas <[EMAIL PROTECTED]> writes: > Derek Atkins writes: > > Ok, what is libgal? I've been successfully compiling without > > it for a while, and I don't seem to have it on my system. > > It's used by gtkhtml, or at least by later versions of gtkhtml. > What version of gtkhtml are you using? > > dave -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
