patches and double druids

[Derek Atkins]

Hi,

Neil Williams <linux at codehelp.co.uk> writes:

> I've fixed the AccountGroup problem with qof_book_merge. There remain one or 
> two problems with some accounts being parented to unexpected accounts but 
> some of this comes down to the example account files themselves. e.g. the 
> Expense account for childcare is a different account type to the one in Car 
> Loan. One has Expenses as 'expense', one as 'liability'. This results in two 
> top level Expenses accounts with different children. I also need to improve 
> the 'best match' code.
>
> 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.

> Do you want me to send in a patch at this stage?

If you think it's ready, sure.

> 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.
At least, I see this in the Changelog:

2004-10-31  Derek Atkins  <derek at ihtfp.com>

        * Neil Williams' QOF Book Merge Patch #2.

So, I'd say "base your patch off of current CVS"  :)

> With the 1.8 branch work, should I leave you in peace for a while longer?
> :-)

Yes, please ;)

> 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.

> 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.

However it may be confusing to the user to click "finish" and then
have another druid pop up.

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.  However IMHO it's the better solution.  Basically it lets you
build "druid components" and then you can combine those components
together into complete druids based on the required process.  I'm
using this for the new import work I'm doing on the qif importer, but
it can be expanded to other gnucash processes, too.  But as I said, it
might be a lot of work to convert the existing druid(s) to the new
format.

> Even on KDE, my current method causes the hierarchy druid to appear and 
> disappear instantaneously - the user is aware of an interruption/flash. Are 
> Gnome druid's modal?

They can be modal, but they don't have to be.

> (I did say I'd need help with the GUI!)

Hehe.  Yes, you did.  :)

-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
       warlord at MIT.EDU                        PGP key available