[Geany-Devel] GTK version policy

[Lars Paulsen]

Hello Lex, hello Matthew,

 > Not sure GTK2 is worth too much effort though.  GTK2 __will__ reduce
 > in usage, especially when GTK4 is out later this year.

I agree to Matthew. You mentioned GTK4. Wouldn't that also be a reason 
to put the things in a common lib?

If I already have compatibility code called in a plugin then later I 
only need to change the compatibility lib/header and not the calling plugin.
(and maybe this is just a "nice thought" because things diverge to much 
;-) But I hope it's possible for the basic GUI things)

But I see that we all do not share the same opinion here and I do not 
want to end up being the only one supporting that approach and:
A: be the only one contributing to a compatibility lib or B: be the only 
one who's using it in my plugin

Don't get me wrong, that's fine. But I will just wait with doing any GTK 
compatibility related stuff before we have a broad agreement in which
direction we want to go with geany plugins regarding GTK2/3/4 
compatibility and related stuff like VTE compatibility.

P.S.: I will leave the PR for the scope plugin open as a reminder. I 
want to port the scope plugin to GTK3 and there is at least one user who is
interested in still having GTK2 support so I would like to support both 
at the end. I will definitely continue the work once the discussion has 
settled.

Greetings,
Lars

On 25.02.2018 00:19, Matthew Brush wrote:
> 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
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel