QIF Importer

[Charles Day]

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.


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