Difference between revisions of "Roadmap"
m (Stick with rand mcnally moved to Makes things much easier) |
m (Reverted edit of Bganu, changed back to last version by Smitty one each) |
||
| Line 1: | Line 1: | ||
| − | + | 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. In progress for 2.2. | ||
| + | |||
| + | = Eliminate deprecated widgets = | ||
| + | |||
| + | 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. | ||
| + | |||
| + | = New database backend = | ||
| + | |||
| + | The current PostGres database backend doesn't have feature parity with GnuCash, and is relatively inflexible to extend. Most of GnuCash is based in the Query Object Framework, and should be integrated closer to there to implement a database backend. | ||
| + | |||
| + | Once done, a database backend should replace the XML file backend as the primary backend for GnuCash, likely using [http://www.sqlite.org/ SQLite] as the implementation. | ||
| + | |||
| + | = 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. | ||
| + | |||
| + | = "Invert" reports = | ||
| + | |||
| + | Right now reports are scheme scripts that programatically generate HTML. They should instead -- at least for HTML generation -- be HTML templates that embed scheme fragments to control looping and variable output. | ||
| + | |||
| + | = 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. | ||
Revision as of 09:43, 16 February 2007
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.
Contents
Register rewrite
The current register is optimized for visual similarity to a "checkbook register" at the expense of simplicity and maintainability. In progress for 2.2.
Eliminate deprecated widgets
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.
New database backend
The current PostGres database backend doesn't have feature parity with GnuCash, and is relatively inflexible to extend. Most of GnuCash is based in the Query Object Framework, and should be integrated closer to there to implement a database backend.
Once done, a database backend should replace the XML file backend as the primary backend for GnuCash, likely using SQLite as the implementation.
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.
"Invert" reports
Right now reports are scheme scripts that programatically generate HTML. They should instead -- at least for HTML generation -- be HTML templates that embed scheme fragments to control looping and variable output.
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.
