Dear Phil, thanks for bringing up this issue now that we managed to get 2.4.0 out.
Am Dienstag, 28. Dezember 2010 schrieb Phil Longstaff: > A few months ago, Christian Stimming started CuteCash with the aims of > replacing gtk by Qt/C++. The idea was that development in gtk/C was too > slow and cumbersome. > So, the big question is: should we set a direction to have CuteCash > replace GnuCash, and if so, what are the steps/milestones to get there? It seems to me my C++ experiment (as I would call it) has still not yet been understood the way I thought, so I'll elaborate a bit on what I did and what my conclusions are. Incidentally, I'm a scientist. If I make some claim, I better get some arguments together that support it. In this case, my claim is that GUI development in C sucks and literally every other modern platform (=programming language plus GUI toolkit and toolchain) can be used much more productively for GUI development. To prove this, I picked the up-to-date platform that I'm familiar with, and which I also happen to like a lot, and checked how much it will take me to get some GUI up and running. The result for my choice of C++ and Qt and cmake: In the four weeks of my experiment, I got a tabbed main window with account hierarchy and register tab windows up and running. And it was only a matter of days to implement even a feature we are still unable to provide in gnucash: Full undo, by consequently implementing the command pattern, which in turn is possible quickly only because the language supports constructors/destructors. (This would suck royally when having to implement this in C.) Here are my conclusions: #1 GUI Coding in C++ is significantly more fun than in C #2 Simple C++ wrappers around our core business objects can be written easily without any need for tight integration into GObject or similar. More intelligence can be added along the way, but very simple wrappers are already sufficient to use those objects in C++ in the way objects use to behave there #3 Some of our features - notably the register widget - are now supported by the modern toolkits so good that even the first code versions will already be faster than what gnucash's register/ledger code provides as widget. Please, please, compile cutecash once, open a register window in there, and compare the speed to gnucash's register. #4 The cutecash code is able to get the "main features" from a programmer's perspective up and running. However, this is still a long distance away from offering the same user experience to our users compared to gnucash. In other words, the main part of the successful user experience of gnucash is in the GUI code, contrary to what I would say first as a programmer. If anyone wants to "just re-implement" all these GUI features that users would mention as the main advantages of gnucash, it would take a long long time. Because of #4, I would suggest not to think about cutecash as a proposed "replacement" for gnucash - unless the way gnucash works is proposed to change in major ways as well. I mean, if some people agree to implement multi-user access, and it shows almost impossible inside the existing gnucash GUI, I would then propose to consider writing a new GUI suitable for this new feature also in a new platform. Cutecash can then serve as an example for re-using old stuff but still writing the new GUI in a new platform. Other features of gnucash can then be copied feature-by-feature along the way, as soon as a developer decides he also wants them in the new framework. Also, as for conclusion #3, I am very sure the same benefits will hold for every other modern GUI platform: Python with some widget toolkit, Ruby with some widget toolkit, you name it. Even Javascript with some widget toolkit (as mentioned by Jeff Warnica in his other message). I think conclusion #3 and #1 (the coding fun) will hold for any of those just as well; only the wrapping code will get more complicated. But I'm curious to be proven otherwise. Experiments, anyone? > So, among the questions I will raise: > 1) Does the current set of engine objects make sense? They currently > are gobjects and CuteCash has C++ wrappers. I guess they need to stay > that way until CuteCash replaces GnuCash, at which point the C++ > wrappers could become the official public API. Yes, the "set of engine objects" (probably also called our "business logic's objects") does make sense, but that's just the result of many iterations to implement the expected use cases. No, for C++ it completely doesn't matter whether they are GObject or not - that's an orthogonal question. Reason: For C++ it only matters what definitions are visible for the compiler (in the headers). GObject classes, on the other hand, go a long way to provide run- time type information and reflection. But this is not helping C++ in any way. It does help a lot for any scripting language, but just not C++. > 2) Does QOF still make sense? Back in the earlier days of the SQL > backend, there was a proposal to replace qof with libgda (gnome data > access layer) which might be a step toward gnucash as a database app. No it doesn't. I consider this yet another shot at trying to get a suitable abstraction layer in between the upper "business logic" and the data store, but I consider this failed. It provides some database logic for the in-memory "database" that's read from the XML file, and if that logic weren't in the qof module, it would have been somewhere else in the code. But with the data store now in SQL, the qof abstraction layer became unneeded. I hope we can get away from this and instead directly talk to a real database driver (or its abstraction) for our queries. > 3) Should I hesitate to introduce new gobjects? One thing I want to do > is replace the current preferences with a better system for managing > global vs per-file preferences on a system vs per-user basis. My idea > is a GncPrefs gobject interface with > get_int()/set_int()/get_string()/set_string()/... functions. These > could be implemented to use gconf on linux, the registry on windows, etc > to better tie into native preferences systems. I think GObject is better than plain C. It won't help you in any way for C++, though. But the work also isn't lost for C++, because most probably a very simple C++ wrapper will sufficiently carry over all of your interesting functionality into C++. GObject will for sure be a large benefit for any scripting language that's already there and that's still to come. > Christian, do you have a roadmap for > CuteCash to help it catch up to Gnucash in functionality? Ok, here's my personal roadmap: I don't have one. My intention for the cutecash experiment is described above. I have found my results from this experiment and I'm done with it for now. I will pick it up again iff I want to have a major new feature added which promises to take so much work that I rather like to do that in C++ than in C. Examples: Multi-user database access, or a much better importing GUI for aqbanking, HBCI, CSV. But currently I don't have the need for any of those (i.e. no "personal itch"). Hence, currently I don't have an area of usage where working on cutecash will give me enough benefit compared with the current gnucash state. In other words, I don't have any personal motivation to push cutecash or any other alternative platform at the moment. Also, since fall 2010 I am in the lucky position of getting paid for coding on gnucash. Customers can ask for specific features added into gnucash, and I'll implement those for them at a normal programmer's rate. For those customers, gnucash is perfectly fine and they are missing only very few additional features, which they found are affordable to be implemented as paid work. For those customers, an alternative platform also doesn't give enough benefit compared with the gnucash, so they just stick with gnucash and are actually quite happy with that. Summary from my side: Cutecash proves that you can achieve the expected GUI quite fast in any other programming platform. For a major new feature, I am sure the benefit of switching platform will be large enough so I encourage anyone to consider this. However, I personally don't see enough motivation for myself to actively promote a new platform, as "my personal itches" are served well enough... The last sentence might change if others with a good motivation chime in, though... Regards, Christian PS: Gee, this message was too long. It should have been split into at least three different messages. If you read until here, I'll give you a beer in case we ever meet :-) _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
