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

[Tobias Markus]

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!

Cheers,
Tobias