On Jan 29, 2008 4:16 PM, Charles Day <[EMAIL PROTECTED]> wrote: > On Jan 29, 2008 6:52 AM, Derek Atkins <[EMAIL PROTECTED]> wrote: > > > "Ian Lewis" <[EMAIL PROTECTED]> writes: > > > > > Charles, > > > > > > I've mostly been playing with the generic importer and seeing how that > > could > > > be applied to the QIF importer. Nothing practical really. At least at > > this > > > point. While the generic importer would allow the reuse of dialogs, > > the QIF > > > importer requires a relatively high amount of user interaction. The > > generic > > > importer isn't a druid so this would mean showing lots of popups. I'm > > > currently at kind of at a loss for how it would best be done so that > > it > > > wouldn't be a worse user experience than what we currently have and > > without > > > introducing too many bugs. I probably need to have a conversation with > > you > > > and/or Derek about it. I wouldn't wait for me necessarily. > > > > What I had in mind was druidizing the generic importer. Pull the > > dialog into a druid page and build the importer around it. I even > > went so far as to build a druid-builder infrastructure so you could > > build a full druid (generically) from a bunch of druid pages at > > runtime, and reuse those pages in multiple druids. So, for example, > > the QIF druid could get built using a different set of pages than, > > say, the OFX importer druid, because OFX doesn't need e.g. the date or > > number format disambiguity feedback, etc. > > > > That sounds pretty nice to me. There certainly should be some benefits in > terms of consistency of the user experience and in code sharing (duplicate > checking in particular). Any opinion on whether to switch from GnomeDruid to > GtkAssistant? GnomeDruid seems to be deprecated from my (very limited) > readings on it. > > However, doing this for the CURRENT qif importer would be fairly > > problematic, I think. > > > > Yeah the code seems like it was written pretty quickly... and the visual > experience is pretty ugly... and it is based on the deprecated GnomeDruid > (which may have been state-of-the-art at the time). But the separation > between the application layer the and GUI layer is pretty decent, as nearly > all of the former is in Scheme and nearly all of the latter is in C. That's > why, in writing patches, I kind of decided to give priority to the Scheme > code because the bugs in there have to be fixed regardless or they'll wind > up getting carried over to the generic importer, whereas any fixes made to > the C code will probably get thrown away. That's my impression anyway. > > > > > I didn't see this bugs before so if you are averse to looking at the C > > side > > > of things I could take a look at them. I'm familiar enough at this > > point > > > with how the druid works to be able to fix something like these but > > you're > > > probably even more famaliar with C than I am. Are they holding you up > > from > > > making other changes? > > > > I think Charles' issue is that there are so many outstanding patches > > that continuing on from now the patches would get confusing as he has > > a patch on a patch. > > > Yes, that's pretty much the situation. If I can give you a little input on > priority, the patches that are most in my way are for 133312 (should be > quick since you've looked at it previously) and 511006, plus the one I > emailed the > list<https://lists.gnucash.org/pipermail/gnucash-devel/2008-January/022273.html>(which > is a no-brainer, just whitespace & comment fixes). The other patches > are fairly small, and while they might fix "critical" bugs, they are not > blocking me because they are unrelated to what I want to change. >
Sorry, that should be 123312, not 133312. > Charles, you could get fix this by using > > something like svk, where you could commit your changes to a local > > branch, or using git-svn (where you can commit your changes to a local > > branch). > > > > Thanks, I'll take a look at those. > > Just a suggestion. I'm not going to be able to get to all your > > work until this weekend at the earliest. > > > > No problem. I'll just try to look at other stuff like the C code. > > > > > Ian > > > > -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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
