C++ work

Aaron Laws dartme18 at gmail.com
Tue Sep 9 15:12:33 EDT 2014


The short question is: What GUI framework is gnucash likely to target in
c++?

I've heard it mentioned that the current framework (GTK?) doesn't make
sense in c++ because it's so gobject-oriented, but I didn't hear anything
else suggested. I know there's a QT effort which seems like a reasonable
way to go, but haven't heard it actually endorsed anywhere.

Currently, c++ work is starting at the deepest point (the part of the code
that is relied on by everything), qof, so that a C api has to be maintained
until everything that relies on QOF has a way of accessing the c++
interfaces. This means that c++ and C interfaces need to be created and
maintained in parallel until everything's ready to switch. This has grated
on me for quite a while, but I see it as a very difficult problem. I don't
see a quick way to fix it. I've tried (and technically succeeded ^_^)
compiling the whole project as c++, but that's not so great because the
dynamic linking doesn't work because of mangling. Repairing this solution
doesn't seem like a profitable way forward. It's sort of like throwing all
your belongings into a river, then swimming across yourself, and trying to
collect everything on the other side, making sure you didn't lose anything.

Another way that I've been trying to consider is to start on the part of
project upon which nothing relies. That way, that part of the project can
be completely C++. Then, take the next thing which doesn't expose a *used*
C api. Rinse and repeat. This way, there will never (?) have to be a
duplicated API in any system.

Another way to think about this is as a tree structure. I'll throw
something up, and I'll eagerly await corrections! Read "->" as "relies on":

GUI (GTK?) -> Business Logic
Alternate gui (WEB?) -> Business Logic
GUI (GTK?) -> Reporting Infrastructure
Business Logic -> QOF
Reporting Infrastructure -> QOF
QOF -> libdrm, etc.

So, if QOF is changed, it still needs to support Business Logic with a C
api until Business Logic is changed which can't happen until all GUIs that
rely on it are changed. If, however, a gui layer is changed, that's all
there is to it; there are no dependencies (if there are, we should have
started at the dependency!). Once all GUIs (I know there's only one, but
I'm trying to create a sufficiently complicated example!) are c++-ready,
the Business Logic can be converted. No redundant API is necessary.

I'm having trouble even evaluating what I'm talking about because I don't
know any details. Knowing which GUI framework development efforts have in
mind would help a ton :-).

In Christ,
Aaron Laws


More information about the gnucash-devel mailing list