[Geany-Devel] [PATCH geany-plugins 02/10] insertnum: Fix GTK+3 support

[Matthew Brush]

On 13-04-06 01:56 PM, Lex Trotman wrote:
> On 7 April 2013 06:31, Matthew Brush <mbrush at 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