[Geany-devel] geany-plugins depends on GIO

Lex Trotman elextr at xxxxx
Wed Nov 17 22:09:09 UTC 2010

On 18 November 2010 03:36, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
> Le 17/11/2010 02:17, Lex Trotman a écrit :
>>> It would need the plugin to something like "dynamically load Geany",
>>> while assuming that Geany has an unstable API. This is IMHO really
>>> complicated to deal with correctly, and I don't think that not having to
>>> recompile a plugin is a sufficient gain for such a pain.
>> Recompiling is not (much of?) a pain for us developers, but it is a
>> pain for other people who use Geany for non-C development.  They might
>> not even have a C development environment, especially on Windows.
>> Using Geany or plugins should not be dependent on being able to build
>> it.
> Under a Linux distribution, it is most likely a non-power-user is using
> it's distribution's packages for both Geany and plugins, and the
> distribution should take care of such things.
> Under Windows, I don't think that upgrading plugins from a binary
> installer is much work for somebody that upgrades it's Geany.
> An I personally feel quite OK about plugins for a software to evolve
> together with the software. But it's my opinion.

But they don't.  Not even all the plugins in Geany-plugins.

>> The static version dependency means that either plugin development is
>> stalled if it needs newer API, or older versions of Geany are not
>> supported.
>> In fact even if no new features are used, a new geany_plugins release
>> will no longer run with an old version.
> Why? AFAIK as far as the Geany ABI hasn't changed, it should still work
> if the plugin depend on a compatible API number, shouldn't it?

ATM how does an older plugin know that a new API is compatible unless
its been re-compiled??

>> To support older versions of Geany, plugin devs need to maintain
>> multiple versions of their plugin and backport bugfixes, lotsa work
>> and doesn't fit into geany_plugins combined releases.  I'm not talking
>> about very old versions of Geany, the problem happens immediately at
>> release of a new version.  Geany maintains compatibility with
>> *ancient* versions of GTK, why then does it require itself to be the
>> latest version?
> Well, well, well...
> I don't really feel good with the idea of a plugin that removes a
> feature of itself when running with some versions of Geany. I don't
> think it is easily understandable for users that to get a feature of a
> plugin they got to upgrade Geany. But well, why not.

I guess I'm more thinking that a new plugin feature won't be available
if it needs a feature that an older Geany doesn't support rather than
removal of existing features.

> But does new API really matters? If a plugin writer wants to keep being
> compatible with old Geany versions, she just have not to use new API --
> as far as the ABI hasn't changed.

But ATM how does a plugin check that without being re-compiled?

>>> I personally think that protecting code with something like
>>>  ...
>>>  #endif
>>> is enough.
>> Yes if you are compiling.
>>> Saying this makes me remember that Geany uses a macro for each function
>>> in the plugin API, so it is actually already possible to do a similar check:
>>>  #ifdef a_geany_function
>>>  ...
>>>  #endif
>>> Well... this gives lot of stuff to think about :D
>> Yes, isn't it past your bedtime again??
> No, but close to it :D


> Regards,
> Colomban
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list