On 13-04-06 01:56 PM, Lex Trotman wrote:
On 7 April 2013 06:31, Matthew Brush mbrush@codebrainz.ca wrote:
On 14-04-06 05:04 AM, Dimitar Zhekov wrote:
[...]
Anyway, I was too categorical. The old hack of #defining GTK_COMPAT_H before including geanyplugin.h, and manually writing any compatibility code, will probably work fine with all Geany versions. That'll look a bit ugly, and IMHO, letting the plugins decide whether to include "gtkcompat.h" would be better...
I agree, gtkcompat.h should be optional, to be included explicitly only if a plugin needs/wants it. It does seem wrong to prevent plugins from targeting older versions of Geany from when this header didn't exist or forcing their min GTK+ to 2.24.
If it does then that is indeed a bug in gtkcompat.h since Geany still supports 2.16. IIUC it defines stuff for versions that need it so the compat functions work on both old and new versions. It certainly creates things for < 2.18 and < 2.20.
The problem is that if you want to target any Geany from before 1.24 where it didn't provide a gtkcompat.h and you use any macros from it, then you have to assume GTK+ >2.16 because gtkcompat.h defines macros that transparently provides GTK+ >2.16 functionality for where that version isn't available. If the gtkcompat.h isn't available and plugins are using macros from it, they implicitly depend on GTK+ >2.16.
As an example, use the "can default" macro, gtkcompat.h defines something like this (paraphrasing):
#if !GTK_CHECK_VERSION(2,18,0) # define gtk_widget_set_can_default(wid, enable) \ if (enable) { GTK_WIDGET_SET_FLAGS(wid, GTK_CAN_DEFAULT); } \ else { GTK_WIDGET_UNSET_FLAGS(wid, GTK_CAN_DEFAULT); } #endif
Say my plugin currently has the (deprecated since 2.18) call:
GTK_WIDGET_SET_FLAGS(wid, GTK_CAN_DEFAULT);
And I change my code to use gtkcompat.h/gtk2.18 call instead:
gtk_widget_set_can_default(wid, TRUE);
Now if gtkcompat.h isn't included (as it won't be in any version of Geany before the next release) and I try to compile my plugin against the older installed Geany headers, rather than getting the macro defined in gtkcompat.h, it's calling the real GTK+ 2.18 function, thus making it depend on GTK+ 2.18.
If we keep gtkcompat.h forced into all plugins maybe we should document the trick of blocking it out by predefining the guard macro like that.
Essentially the plugin API has changed at 1.24, it no longer implicitly includes GTK2, it now implicitly includes GTK2 and GTK3 and the compat functions, and to compile against it plugins do indeed need to change. Such a change was inevitable to be able to move Geany to GTK3 since it isn't compatible with GTK2. gtkcompat.h is always available because Colomban wants plugins to support Geany running on GTK from 2.16 to 3.8.
It works great for Geany core, because you know for a fact that gtkcompat.h is going to be available since it installs it itself. For plugins however, you have no idea what Geany version will be installed, so you can't depend on gtkcompat.h being available.
Cheers, Matthew Brush