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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
