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

[Christian Stimming]

Hi Tobias,

thanks for the interesting work on the gnucash application! I've seen the 
other replies here, but I would like to add some remarks to your proposals 
with a somewhat different direction:

Am Sonntag, 21. Februar 2016, 20:12:58 schrieb Tobias Markus:
> 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.

I think it is great to get some sort of gnucash to run under a more up-to-date 
UI toolkit. I think gtk2 is very much a dead-end, let alone those various 
custom widgets inside gnucash that are even older. However, only very little 
effort is being spent here to switch to a different toolkit. My guess is that 
UI developers who work with modern UI toolkits have long abandoned on gnucash 
development anyway... but that's just my opinion.

> 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.

In my opinion a switch to a new toolkit will be a radical step anyway, so feel 
free to pick as new a version as is convenient to the developers involved.

> Major stuff not yet migrated:
> * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+ 2.
>   I have not yet looked into this.

Yes, that would need some additional effort, because the UI calls that are 
needed in the online banking code (of aqbanking) need some UI abstraction and 
its author decided to implement his own abstraction, resulting in the 
gwenhywfar UI structures. The gwenhywfar UI abstraction has implementations 
for gtk2, qt4, qt5. For gtk3 "somebody" will have to port the existing code 
there to gtk3, too... I can't tell whether any developer here will volunteer 
for this.

> 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.

Yes, absolutely. Autotools has been a pain in the neck for everyone here way 
too long. I'm all for dropping it altogether, the sooner the better.

> * 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.)

Yes, switching to register2 or whatever the more up-to-date version is called 
should also happen better sooner than later. However, this will mean a new 
version will not be as feature-complete as the previous version. I doubt 
whether this is a good goal in any case. Maybe we should be courageous enough 
to just call the old gtk2 code a dead end, including all of its beloved 
features here and there, and just say we will spend our development time only 
in new modern code.

> * 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.

Although most of the current modules are used always and hence better linked 
in statically, there is still some benefit from the module system: Parts of 
our features imply an additional large dependency tree, e.g. aqbanking, or 
postgresql. Making them a module will enable distributions to package them in 
separate packages, so that users will need the aqbanking dependencies only if 
they install the gnucash-aqbanking module, or for postgresql the same. Hence, 
I think gnucash should keep some sort of plugin system in any case.

However, currently due to guile's module loading we have additional 
requirements on the way modules are used. Others here can explain this better 
for sure.

> 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

I agree whole-heartedly that writing UI code in C sucks, royally. For me this 
has been the major reason to keep away from further gnucash development, 
unless I needed some feature myself really badly. I mean, we have 2016. UI 
programming should be done in some programming language that is good for this 
job. C is not. Pretty much any other high-level programming language will do a 
better job here. I don't know Vala so far and I can't judge whether the 
benefits will outweigh enough the (presumed) rather small user base. C++, 
C#/Mono, or Java are known to me and would do the job well enough, but other 
languages are fine, too. Just get away from C w.r.t. UI programming.

As a side note, this might mean the Android App "gnucash-on-android" has a 
huge advantage over the conventional desktop application in that it uses an 
up-to-date programming language. Maybe some time down the road the Android app 
will start to take over the desktop usage of gnucash as well... but  that's a 
different discussion.

> 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, (...)
> 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.

I agree with the statement in general, but I'm not convinced the Gnome 3 HIG 
is a goal I would commit to. As you have read in the other replies, others 
have their doubts about the Gnome 3 HIG as a wortwhile goal, too. On the other 
hand, using just about any HIG will surely improve the usability of gnucash 
just by having more consistency and listening to the thoughts that went into 
the creation of the HIG. So maybe the Gnome3 HIG isn't such a bad choice. But 
as you already saw the choice is currently far from being agreed upon.

Regards, 
Christian