stimming at tuhh.de
Sun Jun 24 16:12:22 EDT 2007
Am Sonntag, 24. Juni 2007 20:22 schrieb Chintan Agarwal:
> Thanks for that information. I could not find the declaration of
> Transaction structure(or its un-typedefed form) per say but from the
> functions in the file, could gather the variable types present.
That is intentional. We don't use direct access to the structure anywhere in
gnucash, and you shouldn't use that, too. Instead, all access is done solely
by the accessor functions in Transaction.h -- that's the whole point of that
file. Do you have doxygen installed? Run "make doc" and a HTML documentation
will be created in src/doc/html/index.html; in that documentation, browse
to "Files" and go to "Transaction.h". This should give a usable overview of
what can be done with a Transaction*.
Having said that, there is also the header file src/engine/TransactionP.h
where you can observe the actual data fields of the Transaction structure.
But as I already mentioned, the structure must not be accessed directly from
anywhere else in gnucash.
> I think that for QIF importer, we could have a simpler structure, akin OFX
> importer wherein the function void gnc_file_ofx_import (void) (in
> /src/import-export/ofx/gnc-ofx-import.c)is the top-level function.
> In such
> a top-level function there are basically three steps:-
> 1) Creating a context for the input data(done by QIF context)
> 2) Parsing the data(done by QIF parser written in /src/import-export/qif)
> 3) Integrating the parsed data into the Gnucash accounts, actions like
> matching, mapping etc.(as pointed out earlier, this is done simply by using
> functions in import-main-matcher.h, specifically the function
> As for the frontend, it would be there only in step 1 as after that the
> parsing process( in the backend) starts and completes.
As a high-level description this is fine. However, I think problems will arise
in the details, especially for the QIF format. But I would suggest you should
commit the first code parts to your branch so that Josh and others can
comment on that directly.
> Some questions:-
> 1) Do the above three steps miss out something vital for QIF import?
Yes - the QIF file format has a whole bunch of nasty ambiguities. For that
reason, there are multiple places throughout the importing process where the
user might have to be asked to resolve some ambiguities (e.g. date format
Year/month/day vs. Month/day/Year vs. whatever). The existing OFX importer is
an example for you to start with, but QIF needs much more interaction with
the user due to these ambiguities compared to the more modern OFX format.
Your proposal above might still be sufficient, but please keep in mind you
will have to add more user interaction along the way.
> 2) The top-level function that would be made should be by what name? In
> other words, which function call results in the QIF import process being
If you're adding your code in the qif-import directory, just start by
modifying the content of the gnc_plugin_qif_import_cmd_new_qif_import()
function and have it create your new dialogs instead.
> 3) Does GNUCash use the standard GNU indentation format?
Currently probably yes, but it's up to the individual developer. There are
efforts to unify the indentation. Once these are put in place, clear
guidelines about the indentation will be given. As long as you haven't been
told anything more specifically, just pick your favorite indentation and
stick to it. GNU format is just fine.
More information about the gnucash-devel