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

[John Ralls]

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 


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.

On Feb 11, 2013, at 1:21 PM, Christian Stimming <christian at cstimming.de> wrote:

> 
> Have a look at the existing cutecash code: In 
> src/optional/gtkmm/gncmm/Account.hpp there's an gnc::Account, and as you see 
> there, the module has a gnc::GncInstance base class that wraps the QofInstance 
> "object" that manages the qof parts. This in turn is derived from Glib::Object 
> which is the C++ version of a GObject.  In my opinion, this wrapping of 
> GObject and also (while it still exists) QofInstance in the end looks very 
> well possible and the resulting C++ classes look well enough like a real C++ 
> class.

Thanks for the pointer. Having a concrete example will be helpful.

What I was thinking was that I'd want to rewrite QofInstance in C++ and then derive Account and friends from it while leaving them as GObjects. As I started to write about that I realized that we don't actually use the virtualization features of GObject, we just manually chain up the superclass functions where we need them, so it's not really a problem. A header full of inline functions to translate those chaining-up functions will do the trick.

For example:

  inline QofBook* qof_instance_get_book (gpointer inst)
  {
      return static_cast<QofInstance*>(inst)->get_book();
  }

Regards,
John Ralls