I had a long, rambling message, but I'll summarize. Please excuse the bluntness. I'm not a Gnucash developer, but could be. My opinions might be technically wrong, and make me a self-destructive asshole, but I'm happy with that.
The question shouldn't be "C++ or not", but "what is the best 2nd/runtime/scripting language?" In 2010/2011, a move to C++ might be a move to easier development for those versed in C & C++, but also a move to relative obscurity. The developers you have might be more productive, but there is a smaller pool of potential developers to pick from. In 2010/2011, given that Gnucash isn't a game, there is really only one choice: Javascript. While http://live.gnome.org/Gjs seems rather dead, http://live.gnome.org/GnomeShell is obviously committed to Javascript (and Gjs as the binding toolkit). The low-level infrastructure is there, Gnome 3.0/GnomeShell 1.0 time frame is shorter then Gnucash 2.6, at the very least. Concerning the "stick with Gnome question", that is always a tricky one. Except to acknowledge that I know that the Gnome types have annoyed a lot of people, the general question is a common one. Stick with HEAD, and ignore let users of older systems? Or try to maintain some long lifecycle for users of older systems. The Gnucash project generally has decided on providing new features to existing users, supporting relatively older low-level packages. For the users who don't want their systems to change, my view is to give them that, and only provide bugfixes; if you want new features, then upgrade to the new version. And if you need to upgrade your distribution, so be it. "Within reason", of course. But as a user of OpenSuSE, within 1 minor version of their most current, I have had to dig around for old version of system libraries to build 2.3.x, and have had to do similar over the past 5 years as well. So no only am I not getting the new features of system library X, I actually have to work to find an old version of system library X. IMHO, the balance is off. Gnome 3 is due out in a few months. It will likely be in "current" versions of distributions about this time next year. OpenSuse, Fedora, Ubuntu, maybe even Debian "unstable", "testing" for sure. If 2.6 is due 22 months from now, that leaves a full 10 month overlap (up to 2 point releases for OpenSUSE and Fedora, depending timing). My personal view is that it is entirely reasonable that you can tell a potential user of 2.6.0 that they will have to have upgraded the OS in the previous year. And it isn't just the functionality (now) provided by Gnome; there are other dependent packages that don't quickly come to mind which are far from current. Not to trivialize those details, but my argument isn't about details :) If polishing low level interfaces up to provide for multiple front ends, then saying "3.0" isn't a bad idea, and with that label, unpleasantness at least has a nice smokescreen. You have to draw a line somewhere, obviously it is best to do that at the beginning of a development cycle. On Tue, Dec 28, 2010 at 10:52 AM, Phil Longstaff <plongst...@rogers.com>wrote: > The subject sounds a bit ominous, but I don't mean it to be. > > 2.4.0 is now out the door. Already there are ideas rolling in about the > next enhancements. I was just about to tackle one of the enhancements > when instead, I thought I would (again) raise a broader issue. > > A few months ago, Christian Stimming started CuteCash with the aims of > replacing gtk by Qt/C++. The idea was that development in gtk/C was too > slow and cumbersome. > > So, the big question is: should we set a direction to have CuteCash > replace GnuCash, and if so, what are the steps/milestones to get there? > > Obviously, since this is all open-source, it's not either/or. One group > could continue with GnuCash as it is while the other develops CuteCash. > Personally, I like the idea of CuteCash and would prefer to develop for > Qt/C++ rather than gtk/C. On the other hand, until CuteCash catches up > in features to GnuCash, if I want any new functionality, it has to go > into GnuCash. > > So, among the questions I will raise: > 1) Does the current set of engine objects make sense? They currently > are gobjects and CuteCash has C++ wrappers. I guess they need to stay > that way until CuteCash replaces GnuCash, at which point the C++ > wrappers could become the official public API. > > 2) Does QOF still make sense? Back in the earlier days of the SQL > backend, there was a proposal to replace qof with libgda (gnome data > access layer) which might be a step toward gnucash as a database app. > > 3) Should I hesitate to introduce new gobjects? One thing I want to do > is replace the current preferences with a better system for managing > global vs per-file preferences on a system vs per-user basis. My idea > is a GncPrefs gobject interface with > get_int()/set_int()/get_string()/set_string()/... functions. These > could be implemented to use gconf on linux, the registry on windows, etc > to better tie into native preferences systems. > > My preference is to work on the under-the-covers stuff and leave the > UI/functionality to others. Christian, do you have a roadmap for > CuteCash to help it catch up to Gnucash in functionality? > > 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
