Difference between revisions of "Cutecash"
(updating of recent design decisions) |
(→Design Decisions: more explanations of currently decided items and still open items) |
||
| Line 52: | Line 52: | ||
==Design Decisions== | ==Design Decisions== | ||
=== Already decided === | === Already decided === | ||
| − | This is a list of design decisions | + | This is a list of design decisions which are already set, i.e. a prototype implementation of the decision outcome is already comitted into [[SVN]]. |
==== Programming Language C++, GUI Toolkit qt4 ==== | ==== Programming Language C++, GUI Toolkit qt4 ==== | ||
| − | The programming language for the GUI is irrelevant to the user, so | + | The programming language for the GUI is irrelevant to the user, so our first goal doesn't weight any choice higher than another. However, for the developer fun it is a must-must to program the GUI in anything BUT C. C is nice for low-level stuff, but today (!) this is just plain wrong to use it for GUI programming. I mean, you also don't manage your hard disk by keeping a table of the nodes by yourself; instead, you use a file system on the hard disk. So for the development fun we must choose a different language for the GUI programming. I ([[User:Cstim]]) happen to have a lot of experience in C++ and it also enables very simple integration of the lower level C parts of gnucash, so that's what I chose for now. Same reason for choosing the Qt GUI framework: For the user it's irrelevant. Technically, several others would be viable options as well. Qt IMHO has the best documentation around, and it comes with qt-designer for easy GUI design, and I ([[User:Cstim]]) happen to know it very well. So that's what I chose for now. |
| + | |||
| + | Some of the implications: | ||
| + | * We use QString for any string inside the code (because in contrast to std::string, QString knows its character encoding, and because of this the conversion between std::string and QString is too clumsy to use it throughout the code, so we just stick to QString) | ||
| + | * The main window with menu, tool bar, and status bar is a QMainWindow instance | ||
| + | * We use the QAbstractItemModel / QAbstractItemView framework (Qt's Model / View implementation of the model/view pattern) for the data display | ||
| + | * Any data manipulation action by the user is wrapped in a QUndoCommand command instance (i.e. the command pattern) so that undo/redo is supported | ||
==== No Plugin Framework ==== | ==== No Plugin Framework ==== | ||
| − | + | Cutecash will not have a plugin framework (i.e. loading plenty of shared libraries at runtime from our code). There is simply no benefit for the user in that. Really. Zero. All enabled or disabled features are known at compile time. Because of this, all of the gnucash/cutecash code will be statically compiled-in and that's it. (One out of several technical reasons for that: The translation framework would turn significantly more complex if other plugins were supplied in separate packages, as they would have to supply their own translations in all languages of the main package. Alternatively, the plugin features would suddenly not be translated whereas the main program is, and nobody wants that.) | |
=== Still undecided, CFP === | === Still undecided, CFP === | ||
| − | Call For Prototypes: These design decisions are | + | Call For Prototypes: These design decisions are clearly not yet set and we kindly invite any proposals (please including prototype implementations, or at least including the willingness to provide it in near future) on how this should be decided. |
| − | * Charts, Charting engine (see e.g. the [http://qt.nokia.com/doc/4.5/itemviews-chart.html Chart example] of qt4 for a pie chart, or maybe Qwt for line charts) | + | |
| − | + | ==== Scripting Language ==== | |
| + | Scripting language (e.g. Scheme, Python, Ruby, QtScript, PHP, whatever). | ||
| + | * Qt's [http://qt.nokia.com/doc/4.5/qtscript.html QtScript] (similar to ECMAScript) offers access to all QWidget properties for free, but for our gnucash data types (Account, Transaction, Split) this doesn't help too much because it would require the gnucash type to be derived from QObject, which in turn implies it is noncopyable, which is a contradiction to the current gnc::WeakPointer approach of a thin wrapper class around the original C object. However, maybe this can be overcome by adding another derivative of gnc::Transaction which uses multiple inheritance from gnc::Transaction and QObject. In this case QtScript would offer access to all member variables rather easily without any extra wrapping code. | ||
| + | * Scheme is already in use. Does it also offer access to Qt? | ||
| + | * Python would probably attract more developers. There is PyQt in case we want to combine it with Qt widgets. | ||
| + | * Ruby? Maybe the coolest language of them. | ||
| + | |||
| + | ==== Charts ==== | ||
| + | Charts, Charting engine (see e.g. the [http://qt.nokia.com/doc/4.5/itemviews-chart.html Chart example] of qt4 for a pie chart, or maybe Qwt for line charts) | ||
| + | |||
| + | ==== Reporting Framework ==== | ||
| + | Should reports be HTML? From a scripting language? Or differently? See also http://techbase.kde.org/Projects/KdeFinance | ||
| + | |||
| + | ==== Menu item manipulation by the active tab ==== | ||
| + | The main window's menus and menu items should adapt to the currently selected tab page (i.e. transaction editing actions should appear only if the tab is a register window), but I don't know how this can be implemented around a QMainWindow the easiest way. | ||
| + | |||
| + | ==== Command-line options ==== | ||
| + | Qt doesn't have a command-line option parser. We can simply stick to glib's GOption, but the potential actions that are accessible through command line options are still open for discussion. | ||
| + | |||
| + | ==== Preferences Per-User ==== | ||
| + | We need to store the persistent per-user settings somewhere (i.e. window sizes and positions). Gnucash uses GConf, which we could use as well (there is also the tiny "libgq" which would bind this to Qt even better). Alternatively we can use QPreferences. Still tbd. | ||
| + | |||
| + | ==== Preferences Per-Book Per-User ==== | ||
| + | We need to store the persistent per-book per-user settings somewhere (i.e. which account register windows are visible). Gnucash uses init files in some known location, which we could use as well. QPreferences can be used for that as well, or we use glib's method for this. Still tbd. | ||
Revision as of 08:59, 22 March 2010
Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.
Contents
Cutecash. Easy to develop, easy to use
Announcing a new sub-project in gnucash: The non-GUI parts are re-used in the state they are, in the C language. This means the double-entry principles and all of the other achievments in the "engine" and xml-backend and eventually other backends can be re-used. But the GUI is rewritten completely new, from scratch, in C++ and using the Qt toolkit. Fun again. The build system is CMake because its configuration runs magnitudes faster. Fun again. And as a final bonus, for MS windows more compiler than before are supported, namely this whole new project can be compiled by MS Visual Studio as well.
http://lists.gnucash.org/pipermail/gnucash-devel/2010-March/027700.html
Vision
This finance software will be developed with the following two goals in mind:
- Create the best possible user experience in a finance management software
- Have the highest possible amount of fun during development
Because of this, design decisions during development will have to be measured firstly by the user's point of view, and radically so. Which one out of many possible design options will give the best user experience? Which option will best fulfill the currently known user requirements? This option is what we will implement. No more, no less. In particular, we will radically ignore all requirements which are currently not yet known, or are not based on the user's point of view.
If this first measure still leaves multiple options to choose from, we will generously choose the option which promises the most fun during development for us, the developers.
If this second measure still leaves multiple options, we arbitrarily but boldly choose one option for now (like Wikipedia's "Be Bold") and move ahead. We might revise the decision later, but then, software has been rewritten many times already, so that's nothing uncommon or to be afraid of. We will just make the decision for now and move on.
Some of these thoughts have been inspired by the book "Getting Real" by 37signals. See http://gettingreal.37signals.com for an on-line copy.
See below for the #Design Decisions which result from these goals.
Build Instructions
Linux
On Linux, install qt4 (>= 4.5.0) and CMake (>= 2.6.0), grab the gnucash sources from SVN, change into its top-level directory and run
mkdir build-cutecash cd build-cutecash cmake .. make ./src/gnc/cutecash
The qt4 development package is called libqt4-dev on Debian-related distributions.
Windows / MSVC
The sub-project Cutecash can be developed with the Microsoft Visual Studio compiler (MSVC) as well. Visual Studio 2008 Express was tested, but others might work as well. However, the Cutecash project needs a large number of dependency libraries which are not built by MSVC, but by the Windows-Mingw compiler (gcc).
The recommended process goes as follows:
- Let the dependencies be build by the mingw installation process which is being used for the "normal" gnucash, explained here: Windows, in particular Windows#Instructions_for_an_.28almost.29_automated_build
- Once all of this is built, you start CMake from http://www.cmake.org. Select the top-level folder of the gnucash source code as source folder; select some new empty folder as build folder. Then click "Generate" and choose a "Visual Studio 2008 project". Subsequently, you will have to select some header file locations and library locations until CMake does not complain about anything anymore, but those have all been installed by the automatic build from Windows#Instructions_for_an_.28almost.29_automated_build
- Next, you open the MSVC2008 project file that was created by CMake, then build this project. The resulting executable can be run and built again and debugged and developed in the normal Visual Studio way.
Design Decisions
Already decided
This is a list of design decisions which are already set, i.e. a prototype implementation of the decision outcome is already comitted into SVN.
Programming Language C++, GUI Toolkit qt4
The programming language for the GUI is irrelevant to the user, so our first goal doesn't weight any choice higher than another. However, for the developer fun it is a must-must to program the GUI in anything BUT C. C is nice for low-level stuff, but today (!) this is just plain wrong to use it for GUI programming. I mean, you also don't manage your hard disk by keeping a table of the nodes by yourself; instead, you use a file system on the hard disk. So for the development fun we must choose a different language for the GUI programming. I (User:Cstim) happen to have a lot of experience in C++ and it also enables very simple integration of the lower level C parts of gnucash, so that's what I chose for now. Same reason for choosing the Qt GUI framework: For the user it's irrelevant. Technically, several others would be viable options as well. Qt IMHO has the best documentation around, and it comes with qt-designer for easy GUI design, and I (User:Cstim) happen to know it very well. So that's what I chose for now.
Some of the implications:
- We use QString for any string inside the code (because in contrast to std::string, QString knows its character encoding, and because of this the conversion between std::string and QString is too clumsy to use it throughout the code, so we just stick to QString)
- The main window with menu, tool bar, and status bar is a QMainWindow instance
- We use the QAbstractItemModel / QAbstractItemView framework (Qt's Model / View implementation of the model/view pattern) for the data display
- Any data manipulation action by the user is wrapped in a QUndoCommand command instance (i.e. the command pattern) so that undo/redo is supported
No Plugin Framework
Cutecash will not have a plugin framework (i.e. loading plenty of shared libraries at runtime from our code). There is simply no benefit for the user in that. Really. Zero. All enabled or disabled features are known at compile time. Because of this, all of the gnucash/cutecash code will be statically compiled-in and that's it. (One out of several technical reasons for that: The translation framework would turn significantly more complex if other plugins were supplied in separate packages, as they would have to supply their own translations in all languages of the main package. Alternatively, the plugin features would suddenly not be translated whereas the main program is, and nobody wants that.)
Still undecided, CFP
Call For Prototypes: These design decisions are clearly not yet set and we kindly invite any proposals (please including prototype implementations, or at least including the willingness to provide it in near future) on how this should be decided.
Scripting Language
Scripting language (e.g. Scheme, Python, Ruby, QtScript, PHP, whatever).
- Qt's QtScript (similar to ECMAScript) offers access to all QWidget properties for free, but for our gnucash data types (Account, Transaction, Split) this doesn't help too much because it would require the gnucash type to be derived from QObject, which in turn implies it is noncopyable, which is a contradiction to the current gnc::WeakPointer approach of a thin wrapper class around the original C object. However, maybe this can be overcome by adding another derivative of gnc::Transaction which uses multiple inheritance from gnc::Transaction and QObject. In this case QtScript would offer access to all member variables rather easily without any extra wrapping code.
- Scheme is already in use. Does it also offer access to Qt?
- Python would probably attract more developers. There is PyQt in case we want to combine it with Qt widgets.
- Ruby? Maybe the coolest language of them.
Charts
Charts, Charting engine (see e.g. the Chart example of qt4 for a pie chart, or maybe Qwt for line charts)
Reporting Framework
Should reports be HTML? From a scripting language? Or differently? See also http://techbase.kde.org/Projects/KdeFinance
Menu item manipulation by the active tab
The main window's menus and menu items should adapt to the currently selected tab page (i.e. transaction editing actions should appear only if the tab is a register window), but I don't know how this can be implemented around a QMainWindow the easiest way.
Command-line options
Qt doesn't have a command-line option parser. We can simply stick to glib's GOption, but the potential actions that are accessible through command line options are still open for discussion.
Preferences Per-User
We need to store the persistent per-user settings somewhere (i.e. window sizes and positions). Gnucash uses GConf, which we could use as well (there is also the tiny "libgq" which would bind this to Qt even better). Alternatively we can use QPreferences. Still tbd.
Preferences Per-Book Per-User
We need to store the persistent per-book per-user settings somewhere (i.e. which account register windows are visible). Gnucash uses init files in some known location, which we could use as well. QPreferences can be used for that as well, or we use glib's method for this. Still tbd.
