Future of Gnucash

[Jeff Warnica]

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 <plongstaff at 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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>