I've got code in the patch just sent to gnucash-patches to correctly
distinguish a QSF XML file from v1, v2 or the older binary GnuCash text
formats and it loads using the QofBackendProvider mechanism rather than as a
GnuCash module.
The patch includes the QSF schema for object and map files, i
Neil,
First, I'd like to say Nice Job! I know you've put a lot of hard work
into this, so I hope my comments below don't discourage you... Also,
I should note that I haven't looked at the patch -- I'm basing my
comments below on your particular statements.
Neil Williams <[EMAIL PROTECTED]> writ
On Tuesday 25 January 2005 9:59 pm, you wrote:
> >On Tuesday 25 January 2005 7:35 pm, Robert Locke wrote:
> >They start off with an opening balance, 0 hopefully, and a series of
> > invoices and payments. The final balance clearly indicates the amount
> > outstanding. If that happens to coincide wi
On Tuesday 25 January 2005 9:18 pm, Derek Atkins wrote:
Ignore that one about balance sheets - I had too many email windows open.
Sorry.
> Neil,
>
> First, I'd like to say Nice Job!
Thanks! I wasted a lot of time last year thinking around the problem of
mapping objects between QOF applications
I wanted to echo Derek's comments: nice job! :)
On Tue, 2005-01-25 at 11:38, Neil Williams wrote:
> I've got code in the patch just sent to gnucash-patches to correctly
> distinguish a QSF XML file from v1, v2 or the older binary GnuCash text
> formats and it loads using the QofBackendProvider
On Tuesday 25 January 2005 10:35 pm, Josh Sled wrote:
> I wanted to echo Derek's comments: nice job! :)
Thanks.
> On Tue, 2005-01-25 at 11:38, Neil Williams wrote:
> > I've got code in the patch just sent to gnucash-patches to correctly
> > distinguish a QSF XML file from v1, v2 or the older bin
On Tuesday 25 January 2005 10:35 pm, Josh Sled wrote:
> > QSF uses UTC time throughout and uses this time format string:
> > #define QSF_XSD_TIME "%Y-%m-%dT%H:%M:%SZ"
> > The datestring must be timezone independent and include all specified
> > fields.
>
> To clarify:
The full reference from the
On Tue, 2005-01-25 at 18:29, Neil Williams wrote:
> The existing methods are used to identify the existing data file types. If
> those all fail, then I parse the document using one of the QSF schema and
> proceed from there. That happens in gnc-backend-file.c, lines 390 onwards:
Got it; thanks.
I've been working on getting a hacked version of libgoffice working
within GnuCash for the Gnome Office Graphing [GOG] support.
It is basically self-contained in `gnucash/lib/goffice/`, and I've it
compiling and working to display basic pie charts in reports. I'm
getting close to a point to commi
Neil Williams <[EMAIL PROTECTED]> writes:
> BTW. Derek - what do you think about enhancing the Doxygen output by tweaking
> the config a little?
Wouldn't be the first time. Although the online docs are off of HEAD,
not g2.
> I use:
> EXTRACT_STATIC = YES
> EXTRACT_LOCAL_CLASSES = YES
Neil Williams <[EMAIL PROTECTED]> writes:
> QOF_TYPE_INT64 and QOF_TYPE_NUMERIC support aren't as robust as I intended,
> but I can fix it.
oops. :)
> At present, if prefix is given to autogen.sh as:
> --prefix=/opt/garfield/qof
> the schemas get installed to:
> /opt/garfield/qof/share/qsf/
>
Josh Sled <[EMAIL PROTECTED]> writes:
> I've been working on getting a hacked version of libgoffice working
> within GnuCash for the Gnome Office Graphing [GOG] support.
>
> It is basically self-contained in `gnucash/lib/goffice/`, and I've it
> compiling and working to display basic pie charts in
12 matches
Mail list logo
