Beyond 2.6 (was:Re: Gnucash 2.5/6)

[John Ralls]

On Feb 8, 2013, at 8:08 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> On 08-02-13 16:20, John Ralls wrote:
>> On Feb 8, 2013, at 7:09 AM, Derek Atkins <warlord at MIT.EDU> wrote:
>> 
>>> Geert Janssens <janssens-geert at telenet.be> writes:
>>> 
>>>> Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is
>>>> only meant to be *ready* to be migrated. This means getting rid of all
>>>> the deprecated gtk symbols. Other than the register this is done. So
>>>> the register rewrite is actually important for this goal, whether we
>>>> use the GtkTreeView approach or the libgnome->cairo route.
>>> Personnaly I'd rather see us move to Qt instead of Gtk3 when that
>>> decision has to be made.  My reasoning is that I think the Gtk
>>> developers have lost sight of their target audience, and as a result
>>> keep removing features that are vital.  It's too much of a loose
>>> firehose, and IMHO shouldn't be supported anymore.  Indeed, for my next
>>> desktop re-install I plan to move away from a Gnome desktop and over to
>>> XFCE..
>>> 
>>> Note that this has nothing to do with the 2.6 release, but it's
>>> something we should think about when contemplating a move to gtk3.
>> I agree completely, with the additional comment that we should consider wxWidgets as well.
>> 
>> However, we should make that decision sooner rather than later: If we're going to drop Gtk, then we should be using C++ and Boost rather than GObject and GLib for backend work.
>> 
>> Regards,
>> John Ralls
>> 
> I did express my interest in Qt before in mails to the list.
> 
> But when you also want to switch to C++ and Boost, to me that sounds more or less like a complete rewrite of GnuCash. We've had this conversation before, and more or less came to the conclusion we don't have enough man power to do that.
> 
> Unless such rewrite can be done in baby steps, spread over several releases, say like one module at the time ? Is such a segmentation possible/practical ?

C is mostly a subset of C++, so a lot of the work is just renaming and fixing headers. The result will be vastly more readable than what we have now. It will work better with SWIG and Doxygen as well: Both are intended for C++, not C. Yes, it's a long term project -- basically a course change on the existing test and refactor -- to be done in stages. It's not hard to make C and C++ interoperate. 

There are two running sores in Gnucash's backend, qof/engine and sql/dbi. The former is a memory-management nightmare and the latter is almost-GObject using the heinous tricks without the memory management framework and clarifying macros (did I really say that? ;-) ). There are two ways to clean them up: GObject or C++ (OK, Objective-C would work, too, but it doesn't have the cross-platform advantages of C++). The rationale behind GObject was that a) Qof and Engine are a large part of the way there, though it was applied a bit haphazardly to an existing non-OO code base, and b) Gtk+ compatibility. If Gtk+ is replaced with a C++ GUI, that argues for a C++ backend instead of GObject simply because C++ is *much* easier to write than GObject code, never mind that it produces much better OO code.

I'm about halfway through the Transaction testing; Account and Split are done. The only other major class in engine is Lots, and it's not that major, so I think I can write its tests fairly quickly. I plan to start on the cleanup immediately after that's done, so I hope sometime this year. I need to know which way to go.

Regards,
John Ralls