This PR adds GTK3 support to the scope plugin, but still keeps GTK2 support (in contrast to PR #697).
Some compatibility code (macros) were put in the common utils lib so that other plugins can use it on porting to GTK3. So this PR includes changes on scope AND utils.
@frlan: don't merge this - it's work in progress.
But this is **NOT working** yet. **I need help** with the build system:
How can I make scope do the following: If build against GTK2 use libvte0.17 or newer, e.g. like this: ``` GP_CHECK_PLUGIN_DEPS([scope], [VTE], [vte >= 0.17]) ``` If build against GTK3 use libvte2.91 or newer, e.g. like this: ``` GP_CHECK_PLUGIN_DEPS([scope], [VTE], [vte-2.91]) ``` Thanks for any help in advance. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/750
-- Commit Summary --
* scope: added GTK3 support (keeping GTK2 support)
-- File Changes --
M build/scope.m4 (1) M scope/src/Makefile.am (6) M scope/src/conterm.c (35) M scope/src/plugme.c (4) M scope/src/prefs.c (6) M scope/src/prefs.h (6) M scope/src/scope.c (4) M scope/src/utils.c (11) M utils/src/Makefile.am (9) A utils/src/gp_gtkcompat.h (57) A utils/src/gp_vtecompat.c (47) A utils/src/gp_vtecompat.h (60)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/750.patch https://github.com/geany/geany-plugins/pull/750.diff
I think you use the [`GP_CHECK_GTK3`](https://github.com/geany/geany-plugins/blob/1.33.0/build/gtk.m4#L24) macro [like this](https://github.com/geany/geany-plugins/blob/4039a13882f4b9e2127f6e7b018bdbdf...).
Untested, but something like this I guess:
``` GP_CHECK_GTK3([vte_package="vte >= 0.17"], [vte_package=vte-2.91]) GP_CHECK_PLUGIN_DEPS([scope], [VTE], [$vte_package]) ```
I'm not sure about the `vte >= 0.17` part in quotes, but I suppose at worst you could figure out what version is the earliest for `vte-2.91` and then have both branches do the version check like this (using `0.48` as example):
``` GP_CHECK_GTK3([ vte_package=vte vte_version=0.17 ], [ vte_package=vte-2.91 vte_version=0.48 ]) GP_CHECK_PLUGIN_DEPS([scope], [VTE], [$vte_package >= $vte_version]) ```
GP_CHECK_GTK3([vte_package="vte >= 0.17"], [vte_package=vte-2.91])
This is swapped, [`GP_CHECK_GTK3`](https://github.com/geany/geany-plugins/blob/1.33.0/build/gtk.m4#L24) uses the first arg if GTK3 is used and the second otherwise.
I'm not sure about the `vte >= 0.17` part in quotes
It should work
, but I suppose at worst you could figure out what version is the earliest for `vte-2.91` and then have both branches do the version check like this (using `0.48` as example):
Yeah, anyway VTE version only grew, even with the newer ABI, so ` >= 0.17` will work fine with any of the ABI names, it'll just be moot for 2.91, but won't be a problem.
@LarsGit223 pushed 1 commit.
2778258 scope: use vte-2.91 for GTK3 and vte >= 0.17 for GTK2
@codebrainz, @b4n: thanks :+1: It seems to work fine.
To be more precise: it works for GTK2 and GTK3 if I compile locally on my machine. But as you can see the Travis CI build failed for GTK3. See the log at https://travis-ci.org/geany/geany-plugins/jobs/387902034. It looks like vte-2.91 is not there: ``` 1459 checking for VTE... no ``` Later it also says: ``` 1739 Scope: no ```
Then it finally fails because the common utils lib is missing a check. How can I tell the utilslib to only compile file ```gp_vtecompat.c``` if vte-2.91 is there? That means if some other plugin requires vte-2.91 to be there, then compile ```gp_vtecompat.c```.
@LarsGit223 pushed 1 commit.
17026ad scope: for GTK 3.4 and higher use CSS padding instead of deprecated 'inner-border' style property
@LarsGit223 pushed 1 commit.
1079a6f Fixed overlapping widgets in 'command_dialog'
@LarsGit223 pushed 1 commit.
bc76140 Corrected missing 'min-content-height' for 'command_view' in 'command_dialog'
@LarsGit223 pushed 1 commit.
83a0cdc Added 'scope_gtk3.glade' to 'POTFILES.in'
I think this looks fine so far. Apart from the ```command_dialog``` I did not find any dialogs which look or behave different across GTK2 and GTK3.
It would be great if someone could help me out with the above mentioned build problem with VTE and the common utils lib. Once that is sorted out I could finish work on this PR and pass it over for review.
@LarsGit223 pushed 1 commit.
2f3f2cf utils: fixed build checks for VTE compatibility code
@b4n @codebrainz @elextr: as you are looking at the debugger plugin now maybe you could also consider merging #750 and #751 for the scope plugin.
I squashed the commits together. It would be nice if this could be merged in the next time somehow. There is also another PR open for the scope plugin. Sorry, I don't want to push anyone - but I also don't like to continue work on a plugin with to many PRs open at the same time.
Is there a way to give me "merge rights" for the scope plugin only? (I assume not because all plugins are in one repository)
@frlan, @b4n, others, do you mind if I merge this without testing (using the web interface)?
Copyright 2017 LarsGit223
IMO, it would be nice to put real names and emails instead of a handle, same for the Git commit author if not done. If someone really wanted to figure out who you are and what your email is, they probably wouldn't have a hard time by searching around on the Internet :)
@codebrainz: true but maybe it at least keeps away some stupid spam robots. Also regarding any programming I prefer to be contacted at github and not per e-mail. So for now, I'll keep it like that.
@codebrainz it doesn't seem sensible to suggest that the "geany-plugins" committers should test every commit of every diverse plugin in the collection when each has its own maintainer who is supposed to be responsible for it, so if the PR is from the maintainer or approved by the maintainer then merge away IMHO.
The plugin was orphaned and I have taken over maintenance in march (see #724).
so if the PR is from the maintainer or approved by the maintainer
and travis approves
then merge away IMHO.
The only obvious exception I can see is things affecting g-p infrastructure for more than one plugin.
@LarsGit223 sorry to hijack your PR for a policy discussion :)
Merged #750 into master.
Well, @LarsGit223 is the maintainer now, Travis says this doesn't break the build, and if it breaks the plugin thats his problem. So merged. (and it can always be reverted).
github-comments@lists.geany.org