On Feb 11, 2013, at 10:53 AM, Phil Longstaff <phil.longst...@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 <christ...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
