Roadmap

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. The developers would love to see the register code being replaced by an implementation based on the GtkTreeView MVC model, but so far nobody has taken on this task again.

Eliminate deprecated widgets and libraries

Gnucash still uses several gtk and gnome widgets that have been marked as deprecated.

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.

The first step, conversion from libglade to GtkBuilder, is in progress.

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. So the "QOF" parts should rather be thrown out.

Some thoughts on what this requires:

• Transactions and splits are by far the object types which cause the most problem.
• Some other objects contain a pointer to a transaction or split (e.g. an invoice contains the pointer to the posting transaction). Either the transaction needs to be loaded when the invoice is or else it needs to be loaded when it is first referenced.
• Some reports generate values by creating a query on splits and then summing them. Given a database engine, a report should be able to query the value of splits for an account or set of accounts on a specific date (with possibly other qualifiers as well e.g. reconcile status). A database engine can do this natively, C code could do it while we're converting, but the API should be defined.
• The set of splits for an account actually is modified with the running balance. xaccAccountGetBalanceAsOfDate() uses this fact by updating the running balances and finding the first balance on or after the date. Instead, the same db query used to get starting/ending balances should be used (sum all splits where account=desired account where date <= desired date). The running balance should be kept by the register because it should be recomputed if the register is resorted or filtered (would close some bugs). (bug #591098 causes the "present" column on the account page to be 0 until the account register is opened if not all transactions are loaded at startup).

Scheme minimization

There are some parts of GnuCash that make a round-trip into scheme code for no really good reason. The developers would like to throw out those parts of Scheme.

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.
• Javascript: WebKit supports javascript so complicated interactivity can be added. Example: ability to expand/collapse levels of the account hierarchy in a report. This could be extended with Javascript interfaces to the API so that all of the report code is written in Javascript instead of Scheme.

Any report module will still need some sort of scripting language to "calculate the numbers". Currently we have Scheme for this, but the developers would like to get away from that. Python might be a better option.

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. The developers would like to replace most of the plugins by one common library or static application, leaving only 2-3 really optional parts as runtime-loaded plugins (e.g. aqbanking).

Object Orientation and Language Selection

Various parts of Gnucash use no objects, GObjects, and rather tortured emulation of objects in C. We are moving forward with a refactoring of these disparate architectures into all-GObjects. Once complete this will greatly improve memory management and provide a more regular API while eliminating a fair amount of duplicate code.

Testing

Most subdirectories have a "test" directory containing tests of varying quality, but the coverage is poor and most of the tests are high-level tests that exercise the full module contained in the directory (for example, the dbi backend tests create a data structure in memory programmatically, then save it to a database and reload it and compare the reloaded data with the originals). These are good tests, but coverage is spotty. (Not all of the ways Gnucash stores data are covered in the dbi backend, for example.)

Modern practice calls for "unit tests" exercising every execution path in every exposed function in a tested module. Maintaining good unit tests during development has been extensively documented as a way to improve both productivity and quality. Gnucash doesn't have many unit tests, but it should.

Integrating testing into the build requires a good testing framework. A rudimentary one is provided as part of autotools, and Glib provides a perfectly acceptable unit test framework, gtest. Unit test frameworks are also available for all object-oriented languages that we're likely to adopt.