[Geany-Devel] GTK version policy

[Matthew Brush]

On 2018-02-23 02:52 PM, Lex Trotman wrote:
> [...]
> 
> As I have been saying for a while, even for existing plugins I would
> make the GTK3 one a separate plugin [...] 

This isn't a good idea because it causes way too much unnecessary 
maintenance burden. To save some #ifdef in a single file to smooth over 
the few differences between GTK+ 2 and 3, you're recommending to 
duplicate tens of thousands of lines of plugin code. This not only 
includes duplicating all of the C code, but also all of the build system 
code, translations, docs, etc.

> With a #ifdefed plugin it takes effort to build it to support both
It's less effort to maintain a compatibility file/module with the few 
differences rather than having loads of duplicated code/infrastructure. 
It causes less burden on contributors and maintainers to edit a single 
code base with a few #ifdef stuff than to try and port changes between 
diverged plugins, or to edit one or the other, further diverging the forks.

To give an example, PR #697 ports Scope plugin from GTK+2 to GTK+3 and 
only touches +57,-26 lines in 7 files. That's roughly the number of 
lines which diverge between GTK+2 and GTK+3 for the plugin, of a total 
of around 12,000 total lines of code in 44 files (estimate of only C 
code using cloc utility). That's around 1% of code which differs between 
GTK+2 and GTK+3; IMO not enough to warrant a fork/duplicate.

> and again to untangle it when GTK2 goes away, with two plugins you just delete one

Going the route of isolating the differences into a single compatibility 
header/module makes it even easier to drop GTK+2 support. For example in 
Geany core C code, we only have to delete the one gtkcompat.h header and 
GTK+2 support is gone. There is surely some other #ifdef stuff mixed 
into other parts of the code, but it's far less work to delete it later 
than the amount of work to maintain separate forks for GTK+2/3 when 99% 
of the code is in common.

Regards,
Matthew Brush