Am Samstag, 18. Januar 2014, 19:20:45 schrieb John Ralls: > > Thanks for fixing the bug! > > > > Note that the functions for using the GDate are still relatively new in > > gnucash. That's why in most cases they are not (yet) being used, even > > though they are more suitable and less error-prone and better altogether > > :-) > And one of the GLib dependencies that we're getting rid of. ;-) > > No worries, though: Boost::gregorian [1] has more-or-less the same > functionality with I hope less work.
Hi John, well, I know boost quite well and I fully agree that date handling is just one more example where boost as a very good and long lasting solution. boost::gregorian for the date, boost::posix_time::ptime for date-and-time points in time, and boost::posix_time::time_duration for differences of date- and-time, and so on. If you're writing some backend code that is in C++ and is allowed to depend on boost, by all means the date and date-and-time types should be taken from there. However, that brings up my actual question: What are your plans for C++ and boost inside gnucash? Is there any sort of migration plan that you have in mind? If the choice were there, I would definitely prefer C++ code over C. However, that still doesn't solve the toolkit questions: C++ with boost, yes, but what GUI? If you want C++ with Qt but still use boost, you've already opened the first set of conflicts (e.g. boost::gregorian vs. QDate and QDateTime; boost is much better, but the qt types are needed for interfacing with the qt widgets). That is just one out of several questions. Under the assumption you already have good proposals for this, I have the next question: What is the migration plan for the gnucash codebase? The unittests cover the current functionality including all its weird and nasty C quirks. When rewriting the engine types as C++ classes, the existing unittests by nature will cover only a smaller part of the new code, so this won't relieve us much here. And a backend C++ class can't be a complete drop-in replacement for an existing C/gobject "object", so we probably can't use the existing GUI code and step by step replace the engine types with C++. What's your idea here? To make the picture complete, a few years back I took the try to add C++ wrapper classes on top of the existing gobject classes using glib's C++ wrapper. The code is in src/optional/gtkmm, and it is being compiled both by --enable-gtkmm and also the cmake project "cutecash". In the cutecash experiment, the wrapper classes were working fine... however they clearly look just like wrappers and still keep their old C gobject pointer around, which is also needed sometimes. The code doesn't look elegant as long as it's still only a wrapper. However, this step enables writing GUI code in C++ while still using the existing engine code. Unfortunately, the more interesting GUI stuff can't be done as long as the wrappers are gobject thingies. I tried to look into implementing a GListView derivative in C++, but gave up because of the impermeable gtkmm and gtk stuff :-( However, the Qt implementation of the list view works quite well in cutecash. Regards, Christian _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
