On Friday 29 October 2004 5:31 pm, you wrote: > Oaf is not a direct dependency, it's an indirect dependency. Gnucash does > not use it, but GtkHtml does (and it's possible that guppi does, too).
It does look like overkill from this side. From my reading of OAF and CORBA, the basic types are very similar, standard C structures can be easily implemented (like enum, struct, typedef etc.), but the whole inter-program communication area is quite a lot to learn. Maybe I'm tired, but when the Hello World example takes several readings to make sense, things start to look like a lot of work. http://developer.gnome.org/doc/guides/corba/html/corba-module-complete-helloworld.html http://developer.gnome.org/doc/guides/corba/html/book1.html I've got another BookMerge patch to send in over the weekend which significantly improves the function of the merge druid but still has difficulty with AccountGroup because the AccountGroup object cannot yet be merged. I've got to work on that and I think I can create parameters that will allow AccountGroup to at least be created and queried using QOF so that when the merged accounts appear in the target book, the GUID for the AccountGroup* parent still exists - that alone should be enough to allow the druid to properly re-parent the new accounts. At the moment, it's failing because any new AccountGroups are not created, leaving the accounts stranded. The code then has to assume that because the *parent is NULL, the account needs to be parented to the root account group, resulting in a flattening of the hierarchy - too many accounts get put as top-level. On a side note, sometimes in this situation, I get an Orphan-GBP account created when I open any account in the book. What is missing from the book to cause GnuCash to create the orphan as a top-level account? It sometimes happens when I have a very limited test book too - i.e. before any merge. I'm going to have to concentrate on getting the next druids done and probably the most useful thing to do now is to hard code the 'map' code in QOF for just what we need. Otherwise, it could take too long before the code that already exists is put to good use. The mapping problem will have to be put off as it is not straightforward and is taking up time that is needed for other code. I'm hoping to get the 'Import Book' druid running next week - it should allow existing books to be merged and that will naturally lead into a third druid that will load partial book information from an XML format, such as that to be created by future pilot-link code. Maybe something like: File -> Import -> GnuCash book File -> Import -> ? It's QOF XML in the code but that means nothing to users. Just 'XML' is too bare and would leave people questioning what XML structure to create. -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
pgpfQBJ0EESk8.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
