Scriptable GUI?

Bill Gribble grib@linuxdevel.com
02 Nov 2001 08:49:45 -0600


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.