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

[Donald Allen]

On Fri, Mar 5, 2010 at 9:54 AM, Donald Allen <donaldcallen at gmail.com> wrote:

>
>
> 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.
>

I should have explicitly registered my agreement with Phil about focusing on
getting 2.4 out. It's just over a year since 2.2.9 was released. While I
don't think that's excessive given the nature of the project and the fact
that the database back-end is a big deal,  I think with some focused effort
on QA and bug-fixing, it can be ready for release in the near future. I
think now is exactly the wrong time to get into an attention-diverting
debate about languages and tools. That can and should wait, in my opinion,
until 2.4 is released and known to be stable.

/Don


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