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

[Phil Longstaff]

On Thu, 2010-03-04 at 21:34 +0100, Christian Stimming wrote:
> I'd like to explain my recent experiments with C++ and cmake: I was tired of 
> the amount of code one has to write in the C language to achieve seemingly 
> trivial tasks. In my day-time projects with other, more GUI-suited, 
> programming languages, the simple tasks can be written sooo much simpler, 
> leaving much more time for the actual challenging tasks. In gnucash, over and 
> over again I thought couldn't the GUI be written in any of the more modern 
> languages and/or toolkits. I mean, can we get the fun into gnucash coding 
> again?
> 
> Actually, we can.
> 
> 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. So here it is:
> 
>   Cutecash
>   Free Finance Software. Easy to develop, easy to use.
> 
> Currently this is only a proof-of-concept for developers: You can load an 
> existing gnucash XML file, and it will show the list of accounts as a flat 
> table in a QTableView. The fun part is how easy it was to add this display of 
> all accounts, so it will probably take only another 1-2 hours until the 
> account list is a tree to be viewed in a QTreeView. And a QTableView with the 
> splits of an account can't be far...
> 
> To give this a try, have qt4 (>=4.5.0) and cmake (>= 2.6.0) installed and:
> 
>   mkdir build-cutecash
>   cd build-cutecash
>   cmake ..
>   make
>   ./src/gnc/cutecash
> 
> Have fun (again)!

I'd had similar thoughts.  The engine and core can be in C and wrapped,
but the app itself can be in another language (c++, python, even java).
I would have aimed at 2.6 (and I suppose that is what you would aim at
as well).

Phil