Zitat von John Ralls <[email protected]>:
[...]
My feeling is that the first option, finishing the GObject
conversion, has the lowest risk. I can start in on it
Thanks for the exhaustive summary. Yes, I agree with pretty much all
of your points. Yes, I've thought about these issues every now and
then as well. Yes, the mix-up of different object systems is a major
issue in the engine.
And: Yes, moving all of our "business logic" ("engine") objects into
GObject seems to me the best compromise in terms of where to spend our
current effort.
I thought about adding C++ wrappers for our engine objects, but ones
that use glibmm's C++ wrapper around GObject. Using those will ensure
that GObject's memory management is properly mapped into the
corresponding C++ object, so that the C++ object behaves correctly.
(Cutecash's C++ wrappers do not behave correctly - they will crash as
soon as a C object is deleted but the C++ wrapper is not and is being
accessed.) If I get around to this, it means any effort on the
GObject'ification of the engine will also give us appropriate C++
wrappers in addition to the C objects with very little effort.
Also, from my understanding having proper GObject objects enables
better wrappers into python or ruby - or at least that was one of
GObject's claimed advantages. But as you said this might have its own
issues and we should currently decide on the basis of what gives us
the most benefit with our current C code.
Regards,
Christian
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
