Future of Gnucash: Most productive platform (programming language and toolkit)?

Christian Stimming stimming at tuhh.de
Tue Dec 28 16:27:48 EST 2010


Dear Phil,

thanks for bringing up this issue now that we managed to get 2.4.0 out.

Am Dienstag, 28. Dezember 2010 schrieb Phil Longstaff:
> A few months ago, Christian Stimming started CuteCash with the aims of
> replacing gtk by Qt/C++.  The idea was that development in gtk/C was too
> slow and cumbersome.
> So, the big question is: should we set a direction to have CuteCash
> replace GnuCash, and if so, what are the steps/milestones to get there?

It seems to me my C++ experiment (as I would call it) has still not yet been 
understood the way I thought, so I'll elaborate a bit on what I did and what 
my conclusions are. Incidentally, I'm a scientist. If I make some claim, I 
better get some arguments together that support it.

In this case, my claim is that GUI development in C sucks and literally every 
other modern platform (=programming language plus GUI toolkit and toolchain) 
can be used much more productively for GUI development. To prove this, I 
picked the up-to-date platform that I'm familiar with, and which I also happen 
to like a lot, and checked how much it will take me to get some GUI up and 
running. The result for my choice of C++ and Qt and cmake: In the four weeks 
of my experiment, I got a tabbed main window with account hierarchy and 
register tab windows up and running. And it was only a matter of days to 
implement even a feature we are still unable to provide in gnucash: Full undo, 
by consequently implementing the command pattern, which in turn is possible 
quickly only because the language supports constructors/destructors. (This 
would suck royally when having to implement this in C.)

Here are my conclusions:

#1 GUI Coding in C++ is significantly more fun than in C

#2 Simple C++ wrappers around our core business objects can be written easily 
without any need for tight integration into GObject or similar. More 
intelligence can be added along the way, but very simple wrappers are already 
sufficient to use those objects in C++ in the way objects use to behave there

#3 Some of our features - notably the register widget - are now supported by 
the modern toolkits so good that even the first code versions will already be 
faster than what gnucash's register/ledger code provides as widget. Please, 
please, compile cutecash once, open a register window in there, and compare 
the speed to gnucash's register.

#4 The cutecash code is able to get the "main features" from a programmer's 
perspective up and running. However, this is still a long distance away from 
offering the same user experience to our users compared to gnucash. In other 
words, the main part of the successful user experience of gnucash is in the 
GUI code, contrary to what I would say first as a programmer. If anyone wants 
to "just re-implement" all these GUI features that users would mention as the 
main advantages of gnucash, it would take a long long time.

Because of #4, I would suggest not to think about cutecash as a proposed 
"replacement" for gnucash - unless the way gnucash works is proposed to change 
in major ways as well. I mean, if some people agree to implement multi-user 
access, and it shows almost impossible inside the existing gnucash GUI, I 
would then propose to consider writing a new GUI suitable for this new feature 
also in a new platform. Cutecash can then serve as an example for re-using old 
stuff but still writing the new GUI in a new platform. Other features of 
gnucash can then be copied feature-by-feature along the way, as soon as a 
developer decides he also wants them in the new framework.

Also, as for conclusion #3, I am very sure the same benefits will hold for 
every other modern GUI platform: Python with some widget toolkit, Ruby with 
some widget toolkit, you name it. Even Javascript with some widget toolkit (as 
mentioned by Jeff Warnica in his other message). I think conclusion #3 and #1 
(the coding fun) will hold for any of those just as well; only the wrapping 
code will get more complicated. But I'm curious to be proven otherwise. 
Experiments, anyone?

> So, among the questions I will raise:
> 1) Does the current set of engine objects make sense?  They currently
> are gobjects and CuteCash has C++ wrappers.  I guess they need to stay
> that way until CuteCash replaces GnuCash, at which point the C++
> wrappers could become the official public API.

Yes, the "set of engine objects" (probably also called our "business logic's 
objects") does make sense, but that's just the result of many iterations to 
implement the expected use cases. No, for C++ it completely doesn't matter 
whether they are GObject or not - that's an orthogonal question. Reason: For 
C++ it only matters what definitions are visible for the compiler (in the 
headers). GObject classes, on the other hand, go a long way to provide run-
time type information and reflection. But this is not helping C++ in any way. 
It does help a lot for any scripting language, but just not C++.

> 2) Does QOF still make sense?  Back in the earlier days of the SQL
> backend, there was a proposal to replace qof with libgda (gnome data
> access layer) which might be a step toward gnucash as a database app.

No it doesn't. I consider this yet another shot at trying to get a suitable 
abstraction layer in between the upper "business logic" and the data store, 
but I consider this failed. It provides some database logic for the in-memory 
"database" that's read from the XML file, and if that logic weren't in the qof 
module, it would have been somewhere else in the code. But with the data store 
now in SQL, the qof abstraction layer became unneeded. I hope we can get away 
from this and instead directly talk to a real database driver (or its 
abstraction) for our queries.

> 3) Should I hesitate to introduce new gobjects?  One thing I want to do
> is replace the current preferences with a better system for managing
> global vs per-file preferences on a system vs per-user basis.  My idea
> is a GncPrefs gobject interface with
> get_int()/set_int()/get_string()/set_string()/... functions.  These
> could be implemented to use gconf on linux, the registry on windows, etc
> to better tie into native preferences systems.

I think GObject is better than plain C. It won't help you in any way for C++, 
though. But the work also isn't lost for C++, because most probably a very 
simple C++ wrapper will sufficiently carry over all of your interesting 
functionality into C++. GObject will for sure be a large benefit for any 
scripting language that's already there and that's still to come.

> Christian, do you have a roadmap for
> CuteCash to help it catch up to Gnucash in functionality?

Ok, here's my personal roadmap: I don't have one. My intention for the 
cutecash experiment is described above. I have found my results from this 
experiment and I'm done with it for now. I will pick it up again iff I want to 
have a major new feature added which promises to take so much work that I 
rather like to do that in C++ than in C. Examples: Multi-user database access, 
or a much better importing GUI for aqbanking, HBCI, CSV. But currently I don't 
have the need for any of those (i.e. no "personal itch"). Hence, currently I 
don't have an area of usage where working on cutecash will give me enough 
benefit compared with the current gnucash state. In other words, I don't have 
any personal motivation to push cutecash or any other alternative platform at 
the moment.

Also, since fall 2010 I am in the lucky position of getting paid for coding on 
gnucash. Customers can ask for specific features added into gnucash, and I'll 
implement those for them at a normal programmer's rate. For those customers, 
gnucash is perfectly fine and they are missing only very few additional 
features, which they found are affordable to be implemented as paid work. For 
those customers, an alternative platform also doesn't give enough benefit 
compared with the gnucash, so they just stick with gnucash and are actually 
quite happy with that.

Summary from my side: Cutecash proves that you can achieve the expected GUI 
quite fast in any other programming platform. For a major new feature, I am 
sure the benefit of switching platform will be large enough so I encourage 
anyone to consider this. However, I personally don't see enough motivation for 
myself to actively promote a new platform, as "my personal itches" are served 
well enough...

The last sentence might change if others with a good motivation chime in, 
though...

Regards,

Christian


PS: Gee, this message was too long. It should have been split into at least 
three different messages. If you read until here, I'll give you a beer in case 
we ever meet :-)


More information about the gnucash-devel mailing list