Cutecash

Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

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:

1. Create the best possible user experience in a finance management software
2. 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:

svn checkout http://svn.gnucash.org/repo/gnucash/trunk gnucash

Get necessary libraries (e.g. on Ubuntu):

sudo apt-get install build-essential libqt4-dev cmake

Then, change into its top-level directory, create a new empty build directory, change into the new build directory, and run "cmake". After this, run "make" as normal. As commands:

cd gnucash
mkdir build-cutecash
cd build-cutecash
cmake ..
make
./src/gnc/cutecash

The CMake step will check for the qt4 development package, which is required for building cutecash. This package is called libqt4-dev on Debian-related distributions.

Windows

The sub-project Cutecash can be developed on Windows as well, both by the Mingw compiler (gcc) and by Microsoft Visual Studio. Visual Studio 2008 Express was tested and verified to create a executable that can be started, but there are still problems preventing its actual use (see below). 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:

• For a mingw build, insert the line WITH_CUTECASH=yes in your custom.sh configuration.
• 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, i.e. run the install.sh script
• The mingw build of cutecash will have an executable in $GNUCASH_DIR/build-cutecash/src/gnc/cutecash.exe

MSVC

For an MSVC build, some extra steps are necessary after the completion of the install.sh script:

• Start CMake. 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. See the section inst_cutecash() in the file install.sh (approx. 80% into the file) for the list of header and library location variables that needs to be set manually.
• 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.

Known Problems

However, it does not yet work in a usable way: All file operations do not yet work due to some collisions of the file-related functions in the C runtime of the glib dll vs. those in the C runtime of the MSVC compiler. To fix this, quite some more work is needed where eventually all file-related calls into the C runtime are no longer being used via the glib DLL but instead are all directed into the MSVC C runtime directly. Some more resources on this:

• See also http://www.gtk.org/download-windows.html
• http://svn.abisource.com/enchant/trunk/msvc/Build.win32.readme , in particular this paragraph:

Glib passes file handles to clients. Libiconv takes a file pointer (in fprintf) from clients. Because these are CRT resources, it is very important that the version of the C runtime library be the same for glib and any dlls that use it. See http://msdn2.microsoft.com/en-us/library/abx4dbyh(vs.80).aspx and http://msdn2.microsoft.com/en-us/library/ms235460(VS.80).aspx for more information.

• And licensing with MSVC-created binaries in general: http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

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 QSettings. 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. QSettings can be used for that as well, or we use glib's method for this. Still tbd.