On Fri, 2001-11-02 at 07:13, Anthony W. Juckel wrote: > I'm realizing that there are some more changes that I would like to make > to the qif import process, but, again, since I don't want to be > dogmatic and force my will upon everyone, I would like to do it by way > of user-centric customization.
Customizability is nice, but you should keep in mind that the transaction matching portion of the QIF import process was just done as a proof of concept. It's not really full-featured enough to be useful. If you have ideas for how to make it better, I encourage you to discuss and implement them with help from the list. It's not forcing your will on people to improve something that's broken or unfinished. > or 2) Alter gnucash to use libglade and allow for user-supplied xml > files, and simply modify the single page in the druid that I'm concerned > with, again, working out all the necessary call-backs in guile. Gnucash alrady uses libglade for its dialogs. However, the QIF import dialog has a lot of C callbacks and you would have to understand much of the guts of this C code. I have largely rewritten the non-GUI parts of the QIF handling and import code; this work got put aside for some other projects, but it's in CVS in the module src/import-export/qif-io-core. The idea was to redo the GUI using guile-gtk (and its guile support for libglade) so that the whole importer would be written in guile. This code is much better and cleaner than the current code, and will very likely replace it before too long, though it's unfinished now. You might want to keep that in mind. In my opinion, it's not really worthwhile to support user-provided replacements for Glade files. The user interface definition and the code that supports it are a unit and it doesn't make sense to provide a user pathway to replacing just the interface. On the other hand, I think if you want to bind another dialog to the "Import" button you should be able to do that, and of course you should be able to load your own code and dialogs at startup. And I think that you should be able both to customize the standard behavior in useful ways and reuse components of the standard dialog if you wish to implement your own replacement that functions much differently. Unfortunately, right now there's not very much support for that in the gnucash application. For example, the buttons and menu items in the user interface are tied to C callbacks that can't be changed without recompiling, making it very hard to modify the user interface from your own code. In the CVS source tree, we are in the process of breaking everything up into loadable modules. The idea is that as we do this, we can go back and clean up the interfaces between the modules. Rather than binding C functions to button callbacks, we can use a more flexible hooks and signals mechanism, for example, allowing loaded modules to easily add buttons, whole toolbars, menus, menu items, etc. If you want to help with this process, your help will be appreciated. It's a lot of work. b.g. _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
