Beyond 2.6

[Geert Janssens]

On 11-02-13 23:01, John Ralls wrote:
> On Feb 11, 2013, at 10:53 AM, Phil Longstaff <phil.longstaff at yahoo.ca> wrote:
>
>> John,
>>
>> what's your view of the best way forward?  I'm confused by what you want to wrap C++ inside GObject.  What's your end vision and what are the steps along the way.
>>
>
> The goal is, as ever, a clean, modern architecture with fewer dependencies. Christian wrote at length last year about how our core library isn't portable because it depends heavily upon Glib. Until that discussion, I'd thought of that as a feature, because GLib provides so many services. But it does tie us to the Gnome ecosystem -- and to MinGW for M$Windows. Plus, it's a lot of work to write GObject code, and when you're done it's hard to understand compared to a proper OO language. Derek's bringing up abandoning Gtk+ popped that out
It's been years since I have written any C++ code and back then never 
got the time to really grasp it. But from the reactions in this thread 
it seems to me most of the developers that have spoken out prefer C++ 
over pure C. That is one point in favour of switching to C++: ideally 
that results in less developer frustration.

My peronal interest is simplified multi-platform support. If we can 
achieve that by slowly moving away from GLib/GObject by using C++ I 
welcome that as well. I don't mind it will take me some time to get used 
to C++. The language in itself interests me for a variety of reasons.

To be clear on this: for me multi-platform support extends beyond Linux, 
Windows and OS X to also the new mobile OS's like Android and IOS. We 
currently don't have much there other than the nice helper app by Ngewi 
Fet. But it's totally independent. Much more could be possible if our 
pure engine were portable to all those platforms. The GUI and the 
features exposed by it can be platform specific. And I'm aware that C++ 
is not Java (for Android),  but many C(++) applications are being ported 
to Android successfully using the Android's NDK, so IMO this is 
realistic for the long term. I have never looked into IOS, but probably 
similar things will be possible there (if not vetoed by all-too-mighty 
Apple).

For this improved multi-platform support, I think we need another 
refactoring in the engine: we should get rid of the guile dependencies 
in there. I think it's ok to have the engine wrapped in guile, but the 
engine core functions shouldn't depend on code written in guile.

Again for all readers: these are long-term targets, not something to 
expect soon. It is all  brought up because it can influence the design 
decisions we are about to make.
>
> I don't really want to wrap C++ in GObject, but I'd prefer to incrementally change the engine and backends to C++, because writing GObject stuff is such a PITA. The current design has a shallow class tree: Everything derives from QofInstance. But it's also a bit tangled, with the different classes being badly interdependent. It would be safer to convert one class at a time to C++, starting with QofInstance, but doing so requires GObject classes to be able to derive from a C++ class. The reverse has already been worked out, because that's how the various OO language bindings for Gtk+ and friends work. That's what the reference to glibmm is about.
I can support this idea. Given my currently weak C++ foo, I would ask to 
add sufficient comments so I can follow what's happening :)

Geert