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

Colomban Wendling lists.ban at xxxxx
Mon Apr 8 18:01:20 UTC 2013

Le 07/04/2013 00:08, Lex Trotman a écrit :
>     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.
> Yes, for plugins to support GTK3 they should require a new API version.
> Colomban should have bumped the API version with the introduction of
> gtkcompat.h since it adds new functionality, then they won't compile
> with older versions of the API, so can't be used with older Geany
> versions anyway.   

Well... not exactly.  The only thing Geany Git adds is macros mapping
GTK functions that may have not been available on version where they are
actually not available.  At worst, it would maybe make a plugin get some
warnings about redefinition of macros if the plugin did the same thing.
 AFAIK this is mostly harmless.

It's true, however, that Geany Git built against GTK3 *has* a different
ABI, and somewhat fakes some API, but who cares since building and
running against GTK3 *requires* GTK >= 3.0 AND Geany >= 1.24.

> The problem is that this new API isn't backward compatible with the old
> API.  This is rare for Geany I admit, and we normally try to avoid it,
> but adding GTK3 to the API makes it incompatible.

Why isn't it compatible?  The API is different if and only if built
against GTK3, something that wasn't possible before.

> If you want to support Geany < 1.24 then you can't support 1.24 and vice
> versa unless you do a bunch of #define and #ifdefs anyway, figuring if
> gtkcompat is available is probably the least of your worries :)

Yes you can, the only thing that this thread shows tricky is that if one
wants to support both (Geany < 1.24) AND (Geany >= 1.24 built against
GTK3).  And even here I can think of relatively easy ways to deal with this.

The easy way I can think of is, instead of trying to do some ugly crap
at undefining GTKCOMPAT_H and running into crazy issues, simply check
whether it's defined or not to see whether it's usable or not:

/* building against a version of Geany providing GTK compatibility
 * macros */
/* no compatibility macros, one may redefine those she needs */

> Anyone who wants to compile for older Geany's should use the 1.23
> tarball or git tag.

Why?  If one wants to target Geany <= 1.23, they don't need GTK3 build,
and then don't seen the smallest difference.  The only thing is that
when developing with 1.24 someone might not notice that they are using
some recent GTK API, but we didn't force anyone to target GTK 2.16
before either.

> Probably that should be clearer somewhere, and
> maybe at the next release of g-p Frank will consider continuing to make
> the 1.23 tarball available with a note in "installing" on the plugins
> website.

Why?  We don't provide builds against each and every one of the older
Geany releases, so I don't see the point.


More information about the Devel mailing list