r20616-20630 (GncOwner)

[John Ralls]

On May 15, 2011, at 10:19 AM, Phil Longstaff wrote:

> I'm looking at what to work on next.  I have a few ideas:
> 
> 1) I want to refactor the preferences system (I wrote an e-mail quite a
> few months ago about this).  My thought was to have a preferences
> interface similar to the java one (a hierarchy of nodes.  A node can
> have child nodes similar to a directory structure.  A node can also have
> leaf entries).  This common interface would provide access to general
> preferences (currently in gconf on all platforms but could be in windows
> registry on a windows system or in macos native config system on mac),
> per-file preferences (currently KVP of the book which also has a
> directory/leaf structure).  We could also add per-user-per-book
> preferences.
> 
> 2) Object extensions.  My idea here is that for each object class (Lot,
> Account, ...), extension classes can be registered (for Account, could
> be tax related, for example).  The extension interface would have
> functions called when an object is created, destroyed, loaded, saved.
> This would fix the "grab an object and stick stuff into its kvp" which
> currently exists and formalize the interface connecting the extended
> data to its main object.  The load/save could store info in kvp, or for
> sql, could store in a new table indexed by main object guid.
> 
> 3) Lots of report work - expand use of eguile/expand use of
> css/javascript - formalize/normalize report engine.
> 
> I'm not sure what itch bothers me most right now.  I'm happy to let you
> (John) take the lead on refactoring the main core.  I also see myself
> more interested in the foundation of a software system rather than its
> UI, so I'm not really interested in redoing UI.

I think (2) needs to wait until we've at least got a good handle on  what the post-refactoring structure is going to look like.

There are several ways to go with preferences, and which one we choose might depend on how tightly we want to stay integrated with Gnome. GLib now provides a generic dbus-like interface which platform devs are expected to write backends for. The most recent versions of GConf now talk to gdbus instead of dbus. GLib also provides a low-level config facility called gsettings, but it's not intended to replace GConf except in the simplest cases. Alternatives are to write a shim class that can interface to the configuration facility of whatever toolkit someone wants to use for a frontend or to just do our own configuration facility and forget about the toolkits in the interest of portablility... that mirrors the alternatives for choosing the class system for the backend... it would be a pain for you to go to spend the summer writing a GObject-based configuration facility only for us to decide in the fall to rewrite the core in Python in which you could have written the whole thing in a week.

Then there's reports. I know that Scheme and Guile are popular with some devs, but I think that it's a serious barrier to both recruiting new devs and to users being able to write their own reports. Since we get a javascript interpreter for free with WebKit, and it's therefore pretty widely understood, I think rewriting the report system in javascript would be a major improvement for Gnucash. (I'm going to crawl into my foxhole now and await the inevitable incoming.)

Regards,
John Ralls