QSF and qof_book_merge

Neil Williams linux at codehelp.co.uk
Sun May 1 08:20:52 EDT 2005

> On Friday 29 April 2005 19:35, Neil Williams wrote:
> > On Friday 29 April 2005 11:02 am, Geert Janssens wrote:
> The thread I was referring to in my message actually was your thread, and 
> already led me to your website, thank you :)
> There's a wealth of information there, and it will take me some more time to 
> grok it all, and ever more time to really figure out the gnucash internal 
> qof  
> object structure and how to map my database structure against it. But I'm 
> working on it.

Define your own objects and let the framework / external processes worry about 
mapping between object types. Try out QOF-generator which will create some 
test objects of your own (and write out sample QSF):
You can run it locally via Apache:
or you can create C code direct from the home page:

It is pre-alpha - but the generated code does compile.

You won't ever import GnuCash objects directly into any program except GnuCash 
- your program can load a file containing GnuCash objects but these will be 
translated into your own objects within QOF - that's the code I need to 
finish. The same works with your code, you don't need to export GnuCash 
objects - it would lead to unnecessary duplication of QOF objects - you 
export your own and then map the changes. Don't worry about the details for 
now, a lot of current map code will change before it's usable.

Naturally, being XML, if there are other ways of converting the objects, those 
can be used too - XSL etc. Mapping is designed for those more awkward 
situations that require calculations, defines, conditionals and loops that 
simply aren't supported in XSL.

> The code for my access application is all in Visual Basic (for historical 
> reasons). I'm not sure if I can make VB work with QOF on Windows (right now, 
> I don't understand QOF at all yet),

That is a TALL order. QOF doesn't build on Windows yet and no-one is currently 
working on that. I'm sure it can be done but I can't say how long it might 
take. Once G2 is out, there have been offers of porting G2 to Windows which 
would have to make QOF portable as well.

> Eventually the Inventory program itself will have to be replaced with 
> something on linux. This 'something' could use QOF, to ease the interfacing 
> with amongst others GnuCash, but the intermediary solution should mainly 
> just  
> do what it's required. There is no need to be able to extend it later, as it 
> is going to be replaced anyhow.

Exactly. Define your application and it's objects as YOU require for your 
program. That is the sensible approach and it's the best way to get the best 
out of QOF. After all, the Q is for Query and you won't get sensible queries 
if the objects have to be translated all the time.

You could use QOF as the query engine of your application instead of an 
external database or you could define QOF objects for structs populated from 
an external database and export those.

It harks back to a previous message in these archives:

Is your program a front end to a database that can use another front-end?
or is your database a backend to the program that can use other backends?

      PROGRAM               or          PROGRAM           PROGRAM
BACKEND      BACKEND                             DATABASE

Do you want your program to work with different databases?
or do you want your database to work with different programs?

QOF can provide data exchange in either situation but the question is central 
to how you design your program.

GnuCash works with different databases. The database is a backend and it can 
be replaced. This is how GnuCash can work with SQLlite, how the postgres 
backend exists and how it also uses XML. One program, multiple backends.

QOF fits naturally into this scheme because it can provide a mechanism for 
adding backends, such as QSF, to an existing program. This is what I've done 
with pilot-link. I've added QOF to libpisock and in doing so added a backend 
as well. QOF has a second backend that is in development - a GUI data mining 
interface called DWI - and that will become available to any application 
using QOF as a library.

Alternatively, if you take the database-imperative to it's limits, you'll be 
creating a data set that can be exported to another database and use any 
number of front-ends.

As QOF has no pre-determined front-end, it can work here too and by doing so, 
it automatically adds more backends. In effect, it gives you the best of 
both. You get an engine that can work with multiple front ends and multiple 
backends, with the same data being mapped or translated between them.

(view in monospace font)

PROGRAM A                                                 PROGRAM B
     |<---------------------->|   |<-------------------------->|
BACKEND A1                     QOF                       BACKEND B1
       BACKEND Q1           BACKEND Q2          BACKEND Q3

In this scenario, backendA1 is incompatible with programB which has it's own 
incompatible backend, B1 that programA cannot use. 

However, all programs linked to QOF can share any or all of the three (in this 
example) QOF backends and adding a backend to QOF adds a backend to all QOF 
programs. By mapping ProgramA objects to ProgramB objects within QOF, the 
data in any of the Q backends also becomes available to both programs.

Work is under way to port the newer QOF code to other QOF applications that 
use internal QOF code like GnoTime and I aim to have all QOF programs using 
QOF only as an external library eventually.

There's nothing wrong with having a backend of your own, it's how GnuCash 
works, as long as there are sufficient QOF objects to import/export all the 
essential data.

> > QSF is an inherent part of G2. It's implemented and working. It produces
> > valid XML, according to the schema, and some export routines are now
> > present. Currently, a bug in the G2 GUI code is preventing the import of
> > QSF data but 99.9% of the required code is again, present and working.
> >
> What exactly is this bug ? I'm willing to look at it.

The Merge Druid stalls. In the G2 port, the GUI code needs to be overhauled as 
it currently won't display the first page but more importantly it won't 
proceed in the conflicts page.

It affects both the File->Add New Account Hierarchy and File->Import QSF.

In the new account hierarchy, the account druid runs fine and the merge druid 
picks up the data successfully. Even after the conflicts have been resolved, 
clicking Forward does nothing.

This worked fine in the 1.8 tree so something is definitely wrong in this 
particular druid. It needs to be re-written but problems exist:
1. The rest of GnuCash uses GtkDialog but there's no GtkDruid, this druid uses 
GnomeDruid instead.
2. There is a GnuCash druid template in G2 that is far more flexible but it's 
not documented. My GUI skills are admittedly poor but I can't make sense of 
the gnc-druid-provider code in src/gnome-utils/

My problem is that I can't see where the actual *contents* of each page are 
defined - I'm almost certainly missing something obvious. (again)
> Also, do you have a sample QSF File I can use for import tests ?

qof-gen can create your own, you can also export QSF files from the current G2 
CVS build. Try the Export Chart of Accounts or the Export under the Business 
features (although you need to have created some invoices / customers etc. 
before you'll get any data).

There are examples on my QSF website.
I'm adding QSF Export routines to GnuCash with each commit. I'm hoping to have 
a export-anything-anyhow druid for GnuCash 2.1 (or possibly 2.0.1)


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050501/6a6e5c91/attachment.bin

More information about the gnucash-devel mailing list