On Tuesday 30 November 2004 4:14 pm, Derek Atkins wrote: > > Should I harmonise the example account trees so that all the accounts > > with the same name are the same type in each? Should it be left to the > > user? > > Yes, that's a definite bug in the example account trees and should be > fixed there.
Will do. > > Do you want me to send in a patch at this stage? > > If you think it's ready, sure. Release early, release often! I'll test with the fixed example accounts later this week. > > Should I incorporate the patch from 31st October into this one or will > > that be applied soon (the one from 31st Oct already includes one from > > 22nd Oct)? > > Uhh, I thought I applied the patch from the 31st Oct into CVS on 31st Oct. Sorry, Derek. I missed that. I'll fix the example account trees and fold those, the Nov 17th changes and the changes since Nov 17th into another patch - possibly this weekend. That will bring CVS HEAD up to date with all my work except QSF (which should be ready for my next patch cycle). My patch process is mostly scripted now and my local gnucash trees are always updated from CVS HEAD before makepatch is run, even if I don't notice! > > It never appears for me in KDE, only when I run GnuCash under Gnome > > (although my Gnome environment may not be complete, I hardly ever use > > it). > > I don't use KDE _or_ Gnome. Don't worry about it, the double druid bug has disappeared from my system too. I was missing nautilus and apt-get install nautilus solved the problem. > > Rather than duplicating all the hierarchy druid glade code inside > > merge.glade, I'm trying to use hide and show (as I would have on > > Windows). I had problems initially when I tried to get merge_druid to > > wait until hierarchy druid had finished. Is that the better way of doing > > it? Call hierarchy_druid, set a flag that tells the hierarchy druid code > > to call merge_druid on finish and do without the first explanation page > > of merge_druid? > > Yes, that is probably the better solution. It's ok IMHO to make the > new hierarchy druid "depend" on the merge druid and behave differently > depending on how it is created. In one case it just behaves in the > standard 1.8 way, in the other case it will jump off to the merge > druid. OK. I'm going to see if I can 'step-over' certain druid pages to further customise the process. It's clunky at the moment and there is potential for confusion with two introductory pages and two Finish pages. ... > However it may be confusing to the user to click "finish" and then > have another druid pop up. Agreed. Now that you've confirmed the above, I'll use some judicious "Next" calls to skip unnecessary windows when hierarchy druid runs at the behest of merge druid. > Another option is to use the (new-in-g2-branch) generic druid code so > you could build your druid pages dynamically based on how the druid is > called. But this may be a lot more work than you want to do right > now. You read my mind! Yes, this will be good for later, right now I just want to get it running properly! Once that's done, I can build the QSF onto qof_book_merge to enable imports from other QOF applications or hand-edited QSF XML AND finish an import routine for existing GnuCash XML v1 or v2 files that also uses qof_book_merge - probably early 2005. This would allow users to merge GnuCash data files into each other (e.g. husband and wife, work and home etc.) and into other backends as available. As the older binary format is still supported in the backend/file, would it naturally follow that wrapping the current backend/file in a second QofSession and then passing that QofBook to qof_book_merge would allow all existing GnuCash files to be imported into any other GnuCash book? Much like the hierarchy druid, a few subtle changes to handle assumptions about the current book may be all that is really needed. File -> Import -> GnuCash file File -> Import -> QSF data File -> Export -> QSF I'd like the export to be selective - as if creating a report that is then saved using the QSF backend (it can handle partial QofBooks that, e.g. contain no AccountGroup or even any specific accounts at all just as easily as it can handle QofBooks built by pilot-link that don't use any GnuCash objects). Export just the customer list, the CoA, just this tax year, just some accounts (all assets or all expenses, maybe all tax related accounts), only the invoices, perhaps even a 'drill-down' operation for reports and customer statements and the like - exporting a single file that contains not just the statement/report but all the data for each category/invoice, just as I can click on the existing statement to bring up a specific invoice. QSF can easily handle partial QofBooks and qof_book_merge will be able to return the data back into GnuCash as and when needed. It could even be a form of groupware - one user works on one set of accounts or customers, another does the invoices etc. with one 'manager' having a book with the summary data, sharing QSF files. I've seen notes on partitioning QofBooks in the source - QSF will write out any QofBook supplied, so simply creating a suitable QofBook, in a second QofSession if necessary, would be all that is needed for the export. I have no idea whether scheme could create a suitable QofBook but it could be fun if it can! > However IMHO it's the better solution. I agree. I'll concentrate on getting the merge/QSF code working and leave improvements to the GUI to a later stage. It sounds like the generic druid will also allow the hierarchy druid pages to appear at the same X window coordinates as the merge druid - currently the hierarchy druid is offset to the side of the now disappeared merge druid. It looks odd and forces an unnecessary mouse movement, just to click Next. > Basically it lets you > build "druid components" and then you can combine those components > together into complete druids based on the required process. Sounds ideal. I'll do what I can with Scrub too so that I can get CVS HEAD fully functional again. I'm lucky in that my self-employment means I can take more time off in December than at other times (even though demand for my paid work is even higher than usual). That'll mean more time for code. What did you think about the QSF improvements? I'm hoping to get that finished by the end of December. I spent a lot of time considering other options to encode the map and when I realised I could use XML after all, it all became very straightforward. As QSF is a file backend and I can reliably distinguish between QSF files and GnuCash XML v1 /v2 files (using schema validation in libxml2), are there particular problems with adding QSF as another backend/file option? Would it simply be a case of adapting gnc_is_our_xml_file() to attempt to validate the file against both QSF schemas and then load the QSF functions instead of sixtp? The QSF validation wouldn't need the const char *first_tag, just the filename and a default for the the name and location of the schemas. (The schema validation is a more rigorous test than currently used for GnuCash XML files.) I'll have to look at how GnuCash uses the environment to find external files too. Some QSF files will need to go in install_dir/share/qsf and some in ~/.gnucash. -- 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
pgpM2Jk6arBM3.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
