Hello All,
I have ported the scope plugin to GTK3. During that work I also noticed some deprecation warnings for the workbench plugin which I did create not long ago and as suggested by the HACKING file I did write it for GTK2.
If I port a plugin to GTK3 should it still support GTK2? Should we change the HACKING file regarding the preferred GTK version to prevent people from writing new plugins based on GTK2?
Just a thought.
Regards, Lars
On 24 February 2018 at 05:53, Lars Paulsen lars_paulsen@web.de wrote:
Hello All,
I have ported the scope plugin to GTK3. During that work I also noticed some deprecation warnings for the workbench plugin which I did create not long ago and as suggested by the HACKING file I did write it for GTK2.
If I port a plugin to GTK3 should it still support GTK2?
For a plugin its up to you if its your plugin, if its a contribution to a maintained plugin its the maintainers decision, IMHO its not worth polluting new plugins with #ifdefs to support both.
As I have been saying for a while, even for existing plugins I would make the GTK3 one a separate plugin. Most plugins have little development happening (except your new one) so it will be rare that changes have to be applied to both. With a #ifdefed plugin it takes effort to build it to support both and again to untangle it when GTK2 goes away, with two plugins you just delete one. And if people do start submitting improvements only for the GTK3 version, thats fine, clearly thats the version that is being used.
Should we change the HACKING file regarding the preferred GTK version to prevent people from writing new plugins based on GTK2?
Personally I vote for that, #1780 for Geany hacking, but the plugins hacking already only says "recommend" not "must" for supporting both GTK 2 and GTK 3.
Cheers Lex
Just a thought.
Regards, Lars
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
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
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@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2018-02-23 11:53 AM, Lars Paulsen wrote:
Hello All,
I have ported the scope plugin to GTK3. During that work I also noticed some deprecation warnings for the workbench plugin which I did create not long ago and as suggested by the HACKING file I did write it for GTK2.
If I port a plugin to GTK3 should it still support GTK2? Should we change the HACKING file regarding the preferred GTK version to prevent people from writing new plugins based on GTK2?
Hi,
For the average plugin with minimal dependencies I would recommend to support both since it's so easy. You can put all of your version specific stuff into a single compatibility header (and/or re-use Geany's) so you don't need to litter your code with #ifdef stuff very much.
Most distros, as well as the Windows and MacOS releases are still shipping the GTK+2 version of Geany/Geany-Plugins and it's the build system default as well, so if you care about supporting a wide user base, supporting both versions is a good idea.
Regards, Matthew Brush
Hello,
I also don't like the idea of having completely separated plugin versions, one for GTK2 and one for GTK3. But I also do not like to have my code littered with #ifdef's.
I am not sure if we can simply handle all things with some macro's in a header. What about writing some compatibility code for the plugins in the common utils lib? So plugins can share the compatibility code and the #ifdef's would only be in the common utils lib. It might mean an extra function call but IMHO that is acceptable.
Regards, Lars
On 24.02.2018 03:53, Matthew Brush wrote:
On 2018-02-23 11:53 AM, Lars Paulsen wrote:
Hello All,
I have ported the scope plugin to GTK3. During that work I also noticed some deprecation warnings for the workbench plugin which I did create not long ago and as suggested by the HACKING file I did write it for GTK2.
If I port a plugin to GTK3 should it still support GTK2? Should we change the HACKING file regarding the preferred GTK version to prevent people from writing new plugins based on GTK2?
Hi,
For the average plugin with minimal dependencies I would recommend to support both since it's so easy. You can put all of your version specific stuff into a single compatibility header (and/or re-use Geany's) so you don't need to litter your code with #ifdef stuff very much.
Most distros, as well as the Windows and MacOS releases are still shipping the GTK+2 version of Geany/Geany-Plugins and it's the build system default as well, so if you care about supporting a wide user base, supporting both versions is a good idea.
Regards, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 25 February 2018 at 07:35, Lars Paulsen lars_paulsen@web.de wrote:
Hello,
I also don't like the idea of having completely separated plugin versions, one for GTK2 and one for GTK3. But I also do not like to have my code littered with #ifdef's.
I am not sure if we can simply handle all things with some macro's in a header. What about writing some compatibility code for the plugins in the common utils lib? So plugins can share the compatibility code and the #ifdef's would only be in the common utils lib. It might mean an extra function call but IMHO that is acceptable.
Hi Lars,
Seems ok.
Not sure GTK2 is worth too much effort though. GTK2 __will__ reduce in usage, especially when GTK4 is out later this year.
But its up to you.
Cheers Lex
Regards, Lars
On 24.02.2018 03:53, Matthew Brush wrote:
On 2018-02-23 11:53 AM, Lars Paulsen wrote:
Hello All,
I have ported the scope plugin to GTK3. During that work I also noticed some deprecation warnings for the workbench plugin which I did create not long ago and as suggested by the HACKING file I did write it for GTK2.
If I port a plugin to GTK3 should it still support GTK2? Should we change the HACKING file regarding the preferred GTK version to prevent people from writing new plugins based on GTK2?
Hi,
For the average plugin with minimal dependencies I would recommend to support both since it's so easy. You can put all of your version specific stuff into a single compatibility header (and/or re-use Geany's) so you don't need to litter your code with #ifdef stuff very much.
Most distros, as well as the Windows and MacOS releases are still shipping the GTK+2 version of Geany/Geany-Plugins and it's the build system default as well, so if you care about supporting a wide user base, supporting both versions is a good idea.
Regards, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel