christian at cstimming.de
Mon Oct 24 15:45:49 EDT 2011
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)
> 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
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
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.
More information about the gnucash-devel