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

Colomban Wendling lists.ban at xxxxx
Mon Apr 8 18:11:32 UTC 2013


Le 06/04/2014 14:04, Dimitar Zhekov a écrit :
> [...]
> 
>> Gtkcompat is supposed to handle compatibility for GTK back to 2.16
>> IIUC, If it doesn't thats a bug :).  Geany's GTK minimum
>> requirement hasn't been increased from 2.16 but it now also can be
>> built with gtk3.  The intention is to encourage plugins to do the
>> same. We are not losing support for gtk2.
> 
> Yes, I understand that, and it provides compatibility as far as I
> can tell without actually using it.

And apparently the test GTK 2.16 builds agree :)

>>> Since I care more about the backwards compatibility than for
>>> gtk+3, my plans are to update insertnum when gtkcompat becomes
>>> part of geany- plugins,
>> 
>> I guess it isn't clearly explained, gtkcompat.h is part of Geany,
>> not the plugins, but they can use it since its only a header file.
>> Its in Geany's Git.  It doesn't become part of geany plugins.
> 
> It's explained well enough. The plugins are not only able, but
> expected to use it, because it's automatically included by
> plugindata.h. But that assumes they are build against Geany
> 2013-03-11, or with a new gtk+.

Plugins are indeed supposed to use it if they want GTK3 compatibility.
Otherwise, they should be able to simply ignore it and work as before.

> The problem is, my company is certified for information securily,
> and getting approval for a new version of any external software is a
> PITA. On the other hand, anything written by the employees, like my
> plugins, is OK by default - we are hired to write software, after
> all... :)
> 
> (Of course, I'm not using the company machines to write any GPL-ed 
> software - only to compile and use it.)

Understandable, indeed.

>>> or when we increase the gtk+ requirements of Geany to gtk+ >= 
>>> 2.24, or after 2 years - whichever comes first.
>> 
>> Not sure why you want gtk 2.24?
> 
> Because GtkComboBoxText is from 2.24 (althought it's [re]defined in 
> gtkcompat.h for any gtk < 3.0, with an explanation why).
> 
>> Anyway its your choice of course, user complaints that it doesn't
>> work with gtk3 will be pointed to you :)
> 
> My package manager shows 2795 depending on gtk+2, and 345 packages 
> depending on gtk+3, which was released on 2011-07-28. :)
> 
> 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,

As you see, it proven to break stuff (unsurprising since it's used in
our headers, the primary reason why we include it implicitly).

However, as pointed out in the other mail, I don't see what would
prevent you from doing a check on whether GTKCOMPAT_H is defined, which
tell you basically whether you have to redefine the things or not.

> letting the plugins decide whether to include "gtkcompat.h" would be
> better...

Since you did read gtkcompat.h comment about GtkComboBoxText, you'll
understand that this isn't really possible:  we expose an API that is
not available in GTK3 anymore, so we ought to do something.   And here
it means either:

1) redefine the symbol if needed (hence gtkcompat.h inclusion)

2) Depend on a GTK version providing the new symbol (here 2.24)

3) Depend on a GTK version providing the old symbol (here < 3.0)

Since we don't want to depend on GTK 2.24, and obviously the goal was to
support GTK3, I went with the option 1.  And again, I don't see why it's
a big deal.


Regards,
Colomban


More information about the Devel mailing list