[Geany-devel] geany-plugins depends on GIO

[Frank Lanitz]

On Wed, 17 Nov 2010 17:36:21 +0100
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.

I think the same, but things Lex mentioned sound also reasonable for
me. Would be a nice thing if its possible without some rocket science.

> > 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?

Yes.

> > 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 agree. Might could cause some confusion also it might introduce a
bunch of other issues in terms of dependencies inside a plugin. 

> 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.

Yes, this is one valid way. 

> >> I personally think that protecting code with something like
> >>  #if GEANY_CHECK_API_VERSION(421)
> >>  ...
> >>  #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

Good night ;) 

Cheers, 
Frank 

-- 
http://frank.uvena.de/en/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20101117/80a1a969/attachment.pgp>