QIF Importer

[Charles Day]

On Jan 29, 2008 4:16 PM, Charles Day <cedayiv at gmail.com> wrote:

> On Jan 29, 2008 6:52 AM, Derek Atkins <warlord at mit.edu> wrote:
>
> > "Ian Lewis" <ianmlewis at gmail.com> 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
> >       warlord at MIT.EDU                        PGP key available
> >
>
>