On Fri, Mar 5, 2010 at 8:42 AM, Phil Longstaff <plongst...@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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
