Revision as of 18:45, 25 December 2010

This list represents is a rough list of ideas that some of the core developers have discussed over the years as the likely next directions for GnuCash. That sentence is mightily-qualified as it should be; this list should not be interpreted as a promise or even really "official"... while it's a good guess as to what one group of people would like to do, projects like GnuCash are the results of a wide group of contributors, and they ultimately decide what road GnuCash travels.

Register rewrite

The current register is optimized for visual similarity to a "checkbook register" at the expense of simplicity and maintainability. It's also written at too low a level, in large part because it was written early in Gtk+-2's lifecycle when the appropriate layout widgets weren't available.

Eliminate deprecated widgets and libraries

Gnucash still uses several gtk and gnome widgets that have been marked as deprecated. An effort is underway to eliminate most of these in the 2.2 release. There is one deprecated widget that can't be removed in that time frame because gtk is missing the equivalent functionality.

Several of the Gnome libraries upon which Gnucash now depends (libart_lgpl, libbonobo, libbonoboui, libglade, libgnome, libgnomecanvas, libgnomeprint, libgnomeprintui, libgnomeui, and libgnomevfs) have been deprecated for several years now, and will be removed from Gnome3, scheduled for release in January 2011. While most distributions will continue to support Gnome 2 for awhile, we'll need to migrate to the newer replacements soon.

In order to continue to provide backward compatbility, this may mean that we have to emulate Gtk+ and have two development branches, one for Gnome 2 and one for Gnome 3.

Database and QOF

Now that we have the DBI backend supporting not just Sqlite3 but Postgresql and MySql as well, we want to move away from a "load everything into memory at the beginning" model to "load only what you need, and take out a backend write lock only on what you're editing" model to allow multiple simultaneous access, to speed up loading large datasets, better data integrity protection, and all of the other benefits provided by a good database.

The current "Query Object Framework" that Gnucash uses rather gets in the way, because while it handles queries acceptably well, it doesn't offer any of the other services that a proper database does.

Generic importer

TSV/CSV importing "simply" needs a dialog to do column-semantics mapping.

Scheme minimization

There are some parts of GnuCash that make a round-trip into scheme code for no really good reason.

Reports

Right now reports are scheme scripts that programatically generate HTML.

Scheme is impenetrable to most programmers. Expecting users to be able to write reports in Scheme is completely unreasonable.

The ideal solution should have three modules:

• Record selection: Ideally graphical with an SQL-like "advanced" option
• Layout: The original item here suggested an HTML template; that could be the "advanced" option, with a simple table/graph being the default
• Style: CSS. It's built into WebKit, we should use it.

Remove module system

The current module system confuses runtime-loaded modules with shared libraries. As well, it is (arguably) at the wrong level of granularity in places, leading to too many modules.

Better MVC split

There is too much application logic in the user-interface handling code. It should move out into some not-yet-fully-defined model layer.

Object Orientation and Language Selection

Various parts of Gnucash use no objects, GObjects, and rather tortured emulation of objects in C. In the second decade of the 21st century, surely it's time to allow gradual replacement with proper object-oriented code written in an object-oriented language. We'll benefit with more readable, more portable, and more easily debuggable code that's also easier and faster to write. While C++ has the advantage that it integrates seamlessly with C and is available as a native language on all three targeted platforms, interpreted languages like Python and Ruby now perform well and are faster to write as well as having rich collections of adjunct libraries already ported to most operating systems which would greatly simplify oru cross-platform maintenance. Many offer integration to multiple native GUIs (Gtk, Qt, Win32, .Net, and Cocoa) which would allow us to offer a better, more native, user experience on non-Linux platforms.