On Fri, Mar 5, 2010 at 9:54 AM, Donald Allen <donaldcal...@gmail.com> wrote:
> > > 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. > 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@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
