-----BEGIN PGP SIGNED MESSAGE----- On Mittwoch, 20. November 2002 19:45, Benoit Gr�goire wrote: > So, let's start the discussion:
Sure. > Here are the GUI services currently offered by the generic import module > It would also need to add: > -Destination account autoselection (auto-split creation) as part of the > transaction matching (There is no choice but to put it on the same page, > there are plenty of examples where two successive transactions will need a > different match) . Err... are you saying that the destination account matching *has* to be on the same page as on the transaction matching/duplicate detection? If that is what you want to say, then I definitely disagree... those are two different tasks and I can easily imagine those happening in different windows (or druid pages or whatever). Maybe you prefer to have both happening in one window (and I prefer the other) -- but if you think that there are important reasons for the one-window concept, can you elaborate more on that? > -Reconcile window invocation (I see it as a list of accounts for which a > balance was downloaded. You check those for which you want to invoque a > reconcile). Since HBCI supports it, is suppose Christian wrote some code > for this. :-) Not really. My "Reconcile window invocation" happens in src/import-export/hbci/gnc-hbci-getbalance.c line 169. Not really much code, is it? :-) In the current HBCI implementation, the user simply gets a dialog window popping up in his face (line 148) asking "Reconcile now? Yes/No", and if the user answers yes, the reconcile window is opened by recnWindowWithBalance from RecnWindow.h. That's all there is. > Now, I've taken a lot of heat in the past for the event based, "pop in your > face" design of the current generic importer. Derek and Christian want it > to be druid based. Ok, this point is still up for discussion, but there are several issues with it, and since you asked, I'm just going to state those: * One thing that keeps buggin me about the gnc_import_add_trans function is that it operates on static, hidden GUI data, which is obvious by the fact that it only takes one argument, the Transaction to add. IMHO the natural question here is "this thing adds transaction TO WHERE?" What I definitely would prefer here is a function like void gnc_import_add_trans(GenericImporter *importer, Transaction *trans); and having the additional function GenericImporter *gnc_import_importer_new (GtkWidget *parent); and so on. Note that this point is still totally independent from the Druid/One-Window discussion. It is, however, clearly not independent from the point you raised about different programming styles colliding here. :-) * Same point (different programming styles): I would kindly ask you that if you define function prototypes in a header file, *please* put the implementation in a .c file *of the same name*. Otherwise the header file IMHO is almost useless -- I still have to grep for the actual implementation of that function, which is quite a bummer. Of course this can lead to the fact that you create a whole lot of header files, and maybe some of those are almost empty -- but IMHO this is totally valid and only reflects the *actual* *real* function interdependencies/ program structure. Note that this point can perfectly be done during the next days, since it shouldn't change the behaviour of the code at all. > To be honest, my motivation for GnuCash isn't at an all time high, and I no > longer have 20 hours a week to spend on ofx and GnuCash as I had in the > last 6 months. Well, everyone here has times of higher spare time for Gnucash, and times of less so. I'd just like to add one comment about that you worked on your code *alone*: I spent all summer fighting with the OpenHBCI programmers about API questions, which mostly were due to different coding styles (literally -- Martin Preuss will easily confirm that). If I had joined you and worked on the same code parts as you did, I would've first needed to start such fights all over again (the above two points are really easy ones :). I eventually decided that the overall outcome for the project is probably higher if I just let your code alone (and IMHO results are confirming that). In other words: You shouldn't feel disappointed because nobody else is editing the files you do -- instead, this has just proven to be the most effective way of dividing up the work, especially in OpenSource projects. Not doing so (i.e. editing the *same* files) immediately requires a whole different level of understanding and communication, which IMHO might be necessary for a big, multi-purpose API (OpenHBCI) but not really for one part inside a big application. Gee. I'm pretty sure we'll come to a nicely working application in the end. Thanks for your comments. Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPdwLP2XAi+BfhivFAQH6nwQAmjec2UjHpNCrhBKk+PwP5s9cuZjiVs1e koryGnXT7o5CKRych/ezq/txoxQ32H0+MCR3hlapQg4pKGjTnAXA1Vjrbt3/GdiA vxW+PFzDy2AjHrBXEk41b1/wWbos5u8xz+gp+XkgqK7hYlXAJU/mVv8Za26ozVml E23gkZIyqUM= =Tnjy -----END PGP SIGNATURE----- _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
