[Geany-devel] geany-plugins depends on GIO
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
> 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
>> 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
>>> #if GEANY_CHECK_API_VERSION(421)
>>> 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
>>> Well... this gives lot of stuff to think about :D
>> Yes, isn't it past your bedtime again??
> No, but close to it :D
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel