patches and double druids

Tue Nov 30 17:52:19 EST 2004

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
-------------- 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/20041130/f31e310b/attachment.bin