Gtkmm

[Christian Stimming]

Am Montag, 24. Oktober 2011 schrieb John Ralls:
> >   1. r21483 - gnucash/trunk/src/optional/gtkmm - [Gtkmm] Add
> >      gnc::GncInstance as wrapper for QofInstance, to be used as a base
> >      class for the derived qof classes. (Christian Stimming)
> >   
> >   2. r21484 - gnucash/trunk - [Gtkmm] For unittests we only need
> >      glibmm, not gtkmm. (Christian Stimming)
> >   
> >   3. r21485 - gnucash/trunk - [Cutecash] Prepare cutecash for
> >      integration of the glibmm wrappers of the engine objects.
> >      (Christian Stimming)
> 
> Christian,
> 
> You're getting *way* ahead of me here. The engine classes aren't
> implemented correctly as GObjects, so they're not suitable for wrapping
> with glibmm

Dear John,

this should not be a contradiction at all. I'm trying to get to know how 
glibmm works, and how wrapping a C GObject in C++ would work. As a usecase, 
I'd like to use those glibmm wrapper classes in the cutecash experiment. The 
previous C++ wrappers in cutecash are not at all correctly implemented as they 
don't know about the destruction of the C object, but nevertheless cutecash 
was already a usable application. Hence, I'd like to check whether the current 
incomplete GObject implementation of the gnucash engine is already sufficient 
to do some trivial GUI design in C++. This is why I'm committing this code.

> , and while QofInstance is, the way it interdepends with
> QofBook is bad. As part of rewriting engine to be correctly implemented
> GObjects, a lot of QOF (QofClass, QofObject, and QofEvent so far) will go
> away

Sure. I've noticed the weird dependency between QofInstance and QofBook as 
well, and indeed, this has to be solved differently in the long run. Also, I 
completely agree the other QOF classes should rather go away. My intention was 
to add glibmm wrappers for the "business logic classes", but not the others. 
As it turned out this has to be the full set of Account / Split / Transaction 
/ Commodity / Numeric / Book, but that's about it.

> -- but I'm months away from even starting on that, and it will
> probably be 2 years before the branch can be merged back into trunk unless
> I get some help.
> 
> Even then it won't be done, though, because I don't think QOF is going to
> work as an object-relational map, so the class structure may well change
> some more to move the querying into the back ends and to do most of the
> computations with queries (because the only objects in memory will be the
> ones currently displayed).

Agreed as well. Again, this is done to learn about glibmm rather than to 
implement some concept that must not be changed again. Instead, it is an 
initial implementation to give us a better understanding when deciding about 
the actual long-term plans.

Best Regards,

Christian