Future of Gnucash: Most productive platform (programming language and toolkit)?
jralls at ceridwen.us
Tue Dec 28 21:09:59 EST 2010
On Dec 28, 2010, at 5:03 PM, Mike Alexander wrote:
> --On December 28, 2010 10:27:48 PM +0100 Christian Stimming <stimming at tuhh.de> wrote:
>> 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 a previous job I was part of a group that reimplemented a significant part of an XML editing and publishing application that consisted of several million lines of mostly C code in C++. My experience with this agrees almost entirely with Christian's comments. The GUI is hard, modern tool kits and languages make it a lot easier, but it's still hard. Unless there is some other reason to reimplement things it probably isn't worth the trouble.
There are two drivers for reimplementation:
1. One of our goals for 2.6 is to enable multiple simultaneous access to a dataset. In order to get there, large swaths of existing code need to be rewritten to interact directly with the database backends instead of sucking everything into memory when the program starts up or the user switches datasets. That code is written partly in ordinary C and partly in sort-of object oriented code using the Gnome GObject library. I don't know if either you or Donald have ever worked with GObject, but it's quite painful.
More information about the gnucash-devel