gnucash simplification [WAS: Re: dialog-options vs. glade]

Josh Sled jsled at asynchronous.org
Wed Jan 5 10:16:03 EST 2005


On Tue, 2005-01-04 at 11:04, Chris Shoemaker wrote:

> Planned Direction:
> 	Specifying my options dialog in scheme was nifty. (I could
> even control layout with the sort order field.)  But I can't seem to
> get it to work for even a date type option, and I eventually visioned
> having a FreqSpec option, too, which isn't already supported by the
> options.scm.  Therefore, this seems like it might be a dead-end.

The options stuff has always seemed like a bit of magic without [enough
of] a commensurate reward.  It's really easy to define a dialog like
that in glade, and populate it with run-of-the-mill editing widgets. 
The callbacks for those widgets can easily enforce constraints and
update a data-model object.

> 	Here's another approach that might work: Specify my options
> dialog using glade; handle property push/pull myself.

Hey, that works well, and is what every other project does. :)  Glade's
really good at layout, and the code can then be well split between the
view [GTK-handling] and model [gnucash] bits if you try for that.

> Reflection:
> 	I guess I was led down this road by
> gnc-plugin-page-account-tree.c, which does use
> gnc_build_options_dialog_contents(), but if I look more closely, I see
> that this page's options don't work anyway. :(

Is that fact in the GNOME2_STATUS file?  [It doesn't appear to be :(]

> 	I knew that there would be a learning curve for gnucash
> hacking when I started -- and it is _large_.  On the bright side,

The curve is WAY too large.  We need to simplify the codebase.  This
should be a priority soon after the gnome2 port is finished ... it's
what I'm looking forward to, anyways.

Specifically:

* invert reporting framework [HTML files with language 
  escapes/templating, not HTML-generating scheme code].
* strip out module system.
* main() in C which loads scheme, not the other way around.
* removing g-wrap dependency.
* simplify register, especially in terms of UI-event handling.
* consistent naming conventions.
* [eventually] removing scheme entirely.

* better split application-logic from UI-handling.

Others?

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`


More information about the gnucash-devel mailing list