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/ > for QOF. > > In GnuCash, for a prefix of: > --prefix=/opt/garfield/gnucash > the schemas are installed into: > /opt/garfield/gnucash/share/qsf/ > > On a standard package install, that would be: > /usr/share/gnucash/share/qsf > (other directories in gnucash/ being bin/ lib/ etc.) > > If you want that to be: > /opt/garfield/gnucash/share/xml/qsf/ > and > /usr/share/gnucash/share/xml/qsf/ > > That's easy. I used qsf/ to distinguish from any other xml formats. Uh, well, /usr/share/gnucash/share/xml/qsf is just wrong, regardless. Keep in mind that we've got two types of installs, --enable-opt-style-install and the 'normal' install. In a normal install with --prefix=/usr the files should go into: /usr/share/xml/qsf or /usr/share/xml/gnucash In an opt-style install with --prefix=/opt/gnucash the files should go into: /opt/gnucash/share/xml or /opt/gnucash/share/xml/qsf I don't have a strong opinion which choices you make. > The QSF usually contains only a partial book and certainly doesn't have to > contain AccountGroup so it can't be loaded as the main GnuCash book - nothing > will show up in the CoA in most cases. It needs to be merged into an existing > book somehow. > > So, you can't really load QSF directly (at least, not always) - on Open, the > final code can inform the user that the QSF will be merged into the current > QofBook, giving the option to abort. Fair enough... In the long run I want to move completely away from XML as a "storage" format. But that's still a ways away. > I will sort out the File -> Import menu later. I just figured that someone, > sometime, is going to try and open the file directly with File -> Open and I > ought to make sure it identified it correctly. Plus it was easier to test it > there than to add a whole new menu option and all the code that goes with it. Sure.. Get it working, then get the UI to work well around it. A pretty UI without any guts is rather useless, no? :) >> > QSF increases the libxml2 requirement to 2.6.0 for the gnome2 branch to >> > support the schema validation which identifies QSF files relative to >> > existing files. >> >> This is a major issue. Our target platform has libxml2-2.5.10, not >> 2.6. We cannot depend on 2.6. > > I thought it was OK to go to 2.5.2? I just thought I'd play safe by going > for > 2.6. 2.5.2 is okay. 2.5.10 is okay. 2.5.11 is maybe okay. 2.6 is not okay. > https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012511.html >> > FWIW, requiring libxml2 >= 2.5.2 shouldn't be a problem. Even RH9 >> > (updates) distributes 2.5.4, and FC1 uses 2.5.11 by default. So I >> > don't see this as a problem. > > I can go back to 2.5.2 but schemas simply weren't supported before that. > > There may be a few problems at 2.5.2 - schemas were very new - but it should > be OK - I'm not making huge demands on the schema code, at least not until I > get to grips with KVP. You don't have to go back to 2.5.2; but you should go back to 2.5.10. RHEL3 ships 2.5.10. FC1 ships 2.5.11. Those are the target platforms, IMHO, so it should work with those versions. The fact that it continues to work with 2.6 is a Good Thing, but it should work with 2.5.1[01]. >> Why is QOF_TYPE_KVP a challenge? > > Maps. I knew this would be the hardest part and it's not disappointing me. > :-( I dont understand? Assume gnucash<->gnucash -- why is KVP so hard? (Keep in mind that I'm significantly less interested in gnucash<->non-gnucash ;) > Trying to calculate KVP frames from other object data is not my idea of fun. Why? You know that a transaction note maps to <kvp type="string" path="/notes"> so I would think that would be relatively easy to map, no? > If I can handle them as defaults, booleans or some other lookup method, I > will. I'd rather have 6 user defaults than a 6 level tree within the QSF. It > makes validation a pig and it makes mapping v.complex. See josh's comment about validation. IMHO (and in my personal experience) validation is a lot of overhead for very little gain. Just throw an error when you actually parse the data if you see something in the document that you don't expect and can't handle. Gnucash has lived without validation for, what, 4, 6 years now? Has it suffered horribly for the lack of validation? I certainly don't think so. -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] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
