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

[Donald Allen]

On Fri, Mar 5, 2010 at 8:42 AM, Phil Longstaff <plongstaff at rogers.com>wrote:

> 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)!
>
> It doesn't seem able to read any of my XML files.  Oh well.
>
> While this may be/is guaranteed to restart the various language wars
> (can we do this in Visual Basic, please :)), I think it's a great idea -
> use the best tools available for different parts of the code.
>
> Someone (John Ralls?) asked why we would keep the core in C.  Wx vs Qt
> came up.
>
> I'd like to see discussion of why different technologies would be used
> for various parts of the system.  What features does the engine need?
> Why C++ for the UI?  Would we do better with a language using garbage
> collection so that we don't need to worry about memory?  How would this
> coincide with rewriting Gnucash/Cutecash as a database app?
>
> I would also like to suggest that work on this take a back seat to
> getting 2.4 out the door.  Boring, yes, but there are lots of bugs in
> bugzilla.  Can we go through and identify which ones we would like fixed
> by 2.4?
>

I'd like to second Phil's comments, with which I agree completely. While I
don't have any standing as a Gnucash developer, I've worked on and managed
large software projects for a long time, so I do know something about the
issues being raised here.

In particular, I think choosing C++ for a UI re-write deserves some
discussion. Phil raised one of the issues -- lack of memory management. My
personal opinion of C++ is pretty low -- I think it's far too complex,
needlessly so (and yes, I've written C++ code myself and read a lot more of
it, mostly in a pretty horrified state). Yes, I understand that it's widely
used, but that doesn't mean it's good. I would cite Windows as an example of
this phenomenon. And while it's widely used, I think it's difficult to find
people who can write clean, readable, understandable code in C++, something
that I think is key to a project like this, where code needs to pass easily
through the eyes and brains of multiple people. So I would urge the Gnucash
powers-that-be not to view C++ as a default, if there really is a desire to
move to more modern languages than C. If C++ is ultimately chosen, it should
only be after careful consideration of all the alternatives.

/Don



>
> Phil
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>