[RFC] GTK+ 3 Migration - Alpha-grade Patchset

[John Ralls]

> On Feb 21, 2016, at 11:12 AM, Tobias Markus <tobias at miglix.eu> wrote:
> 
> Hi GnuCash developers,
> 
> over the last few feeks, I have developed a fundamental patchset that
> should get GnuCash up and running in GTK+ 3.
> 
> The source code is available at GitHub:
> https://github.com/hesiod/gnucash/tree/gtk3
> 
> Some independent commits are on the next branch. All GTK+ 3-related
> stuff is on the gtk3 branch.
> 
> I'm sorry for the sometimes messy commits, but the number of commits is
> quite massive already and I really didn't have the time splitting them
> up. If you have any questions regarding a particular commit, feel free
> to ask me.
> 
> DISCLAIMER: This is alpha-quality software and not at all ready for
> users! Please do not run GnuCash built from my development tree unless
> you want to contribute to the development process. This development
> version may delete all your data and eat your CPU!
> 
> While I got GnuCash pretty much working under GTK+ 3, a lot of further
> (fundamental and architectural) changes are required before even
> thinking about a release. Simply spoken, we now have GnuCash working in
> GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to go
> down this path, the user experience will be substandard, especially
> compared to the current releases.
> 
> Because GnuCash 2.0 was (afaik) coupled to the GTK+ 2 migration, I
> suggest that the GTK+ 3 version should be GnuCash 3.0.
> 
> A quick word on dependencies: I set the minimum GTK+ version to be 3.18
> because I didn't try to compile it with any earlier versions, but
> backporting probably isn't too hard.
> 
> Major changes already in my tree:
> * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were replaced
>   by abstract GActions/GMenus. This doesn't sound like a lot, but is a
>   major change. Please read the relevant API documentation and do not
>   hestitate to ask me if you have any questions about the new GAction-
>   based infrastructure. Sorry for not going into more detail,
>   but describing the technical peculiarities here would take
>   considerably too long.
> * I removed the splash screen and replaced it by GApplication's busy
>   notification in some places.
> * I updated the HTML code to use the Webkit2 API, but it needs some
>   more love.
> * Using GtkApplication renders everything related to
>   gtk-osx-integration unnecessary.
> * This is unrelated to the GTK+ 3 migration, but I added a Markdown
>   version of the README and added a DOAP project description.
> * I changed the action naming pattern from CamelCaseAction to
>   dot.separated.action-name, e.g. file.close or account.d
> 
> Major stuff not yet migrated:
> * In order to migrate the small business module, its entry ledger has  
>   to be rewritten, just like the "normal" register.
> * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+ 2.
>   I have not yet looked into this.
> * I removed the old file history/recent files code. There are better
>   ways to do this in GTK+ 3.
> * I haven't converted every UI definition file to the new format for
>   now.
> 
> Things that I recommend be dropped/removed for GnuCash 3.0:
> * Maintaining both the CMake and autotools-based build system does not
>   seem like a good idea, so drop autotools.
> * Rewriting the old register is not really viable or useful,
>   so drop it. Currently, either the old or the new register is compiled
>   to ease transition. (Right now, the new register can be enabled in
>   addition to the old register.)
> * The dynamic module system (based on GModule) is a nice idea, but the
>   
>   benefits are dubious at the moment. While the dynamic loading of all
>  
>   the standard modules incurs a heavy startup delay, there is no
>   reason why a user would not want to load all the built-in modules.
>   Therefore, all GnuCash modules should be converted into statically
>   linked objects. (It is still possible to compile shared libraries
>   for Guile at the same time, CMake should have no problem doing
>   that.)
> 
> Major Changes that I highly recommend for a GnuCash 3.0 release:
> * Writing GObject-based code (i.e. GTK+ code) in C is a very cumbersome
>   and boilerplate-ish process. Vala makes it possible to write GObject
>  
>   code in a very concise way, all while compiling directly to C source
>  
>   (and C headers), making it possible to seamlessy integrate Vala code
>   into C code. Other C-to-Vala ports have seen significant decreases in
>   
>   code size. Porting the UI code to Vala should definitiely ease
>   maintainability, correctness and readability without sacrificing
>   performance.
> * I ported the core application code to use GtkApplication. It would
> be 
>   nice to change the main window - opened file relationship from the
>   current N:1 to a 1:1, i.e. each main window is separate and has
>   exactly one opened file. This would simplify the main window code.
>   It also seems more intuitive than the current behaviour, since the
>   user does not expect that all windows change the opened file if he
>   opens a file in one window.
> * UI design: see below
> * I have not yet looked at translations and accelerators.
> * The new register requires some more love.
> 
> Nice-to-haves regarding GTK:
> * Some GSimpleActions would be better off as GPropertyActions.
> * Validate all GtkBuilder files using gtk-builder-tool.
> * File Chooser Dialog: Implement proper file format filter.
> * xdg-app support
> * jqplot as a Git submodule
> * Have hints for GtkEntries
> 
> Nice-to-haves, other that the UI:
> * Replace the GncInt128 with Boost.Multiprecision
> * I added initial configuration files for clang-format and clang-tidy.
>   The latter could be integrated as a Git commit hook.
> 
> Bugfixing paths:
> * I have added basic support for compiling GnuCash with the address
>   sanitizer (ASan) and the undefined behaviour sanitizer (UBSan),
>   although in practice, the former only works using LD_PRELOAD at
>   runtime (which is discouraged) due to a Guile error.
> * Many of the warnings you see compiling my tree really are valid
>   errors and should be fixed.
> 
> UI Design Notes:
> 
> The current UI has the menubar as the central element. Depending on    
> which "plugin page" you're currently looking at, certain menus are
> shown or hidden, e.g. the "Transaction" menu is only visible when
> viewing a register page. In theory, this behaviour is also available in
> my development tree thanks to the EggMenuManager (taken from Gnome
> Builder), but I removed the relevant calls for the moment. Please read
> on for the reasons. (Search for calls to egg_menu_manager_remove)
> 
> Both the heavy usage of menus and the context-sensitive visibility of
> menus are discouraged by the Gnome 3 HIG. A more modern UI design would
> greatly benefit the GnuCash user experience. (Before continuing, please
> have a quick look at the Gnome 3 HIG right now if you haven't yet.)
> 
> I haven't spent a great deal of time thinking about a potential new UI
> design yet, but in general, it boils down to having the page-specific
> actions as buttons inside a toolbar, and general actions in a header
> bar (GtkHeaderBar). As an example, let's take the register:
>  * New Account: A plus button on the toolbar
>  * Register Style: Clicking on "sandwich"-like button opens a popover
>    offering the different styles as a slider (as in Nautilus: the
>    button left of the sandwich button offers the different Nautilus
>    style options)
>  * View - Search by: As "search" button in the header bar
> 
> In general, you can get a lot of design inspiration by looking at Gnome
> Apps, in particular some of the recently refreshed ones, e.g.
> Files/Nautilus, Videos/Totem, Maps, Documents or Document Viewer/evince.
> 
> Asking the Gnome Design Team for suggestions is also a possible avenue.
> 
> Thanks for your time and attention - let's make GnuCash an even better
> free software finance manager!
> 

Dear Tobias,

That's a huge amount of work, but it's a bit too far-reaching to be considered a patch set and it doesn't really look like something we can merge.

It's also quite possible that we won't ever move GnuCash to Gtk+-3. We haven't decided on a future UI toolkit and if you'd looked at http://wiki.gnucash.org/wiki/Roadmap you'd realize that we have other priorities. Unfortunately it doesn't look like many of your changes advance those priorities, and the way you've done your changes would make it very difficult indeed to cherry-pick out the parts that might be useful. 

Had you come here before starting work we could have guided you towards work that could be merged and coached you about making commit messages, style, and the like. Perhaps you'd consider starting over?


About your recommendations:
* We probably will drop autotools in favor of cmake for the next release.

* Vala is not useful to GnuCash. It is usable only with Gtk+ and we need to be able to write GUIs for other platforms. We decided two years ago to redo the guts in C++11 and are working on that.

* Agreed that rewriting the old register isn't attractive, but a developer spent a year trying to get a new GtkTreeView-based register to work right and although he got close, it wasn't suitable for release. I presume that your Gtk3 port is based on that "Register2" code, and since you say that your work isn't releasable either that doesn't augur well for that line of development.

* The dynamic module system is indeed a complication of dubious utility, but Guile works by dlopening libraries; one doesn't dynamically link them. Having GnuCash's executable statically linked and Guile using dlopened shared libraries won't work: They pass objects back-and-forth between each other so they need to use the same binary image. The Gnucash executable might be able to dynamically link the shared libraries instead of dlopening them on startup. It's worth trying out. We do have a long-term goal of getting Guile out of the middle of GnuCash and that would make static linking more feasible.  

*We (I) did extensive performance testing with several multi-precision libraries including boost.multiprecision and found that their dependence on the free store made them unacceptably slow. GncInt128 uses the same algorithms (they're in Knuth) but is stack based and so substantially faster than boost.multiprecision. The gory details can be found by following the long thread beginning at https://lists.gnucash.org/pipermail/gnucash-devel/2014-May/037723.html.

* We certainly recognize that GnuCash's GUI design is a bit dated, but a redesign depends to a large degree on the toolkit one uses. Since we're not ready to choose a new toolkit we're also not ready to undertake a major redesign. Regardless, the Gnome3 HIG is unlikely to factor much in our design decisions.


Regards,
John Ralls