On Wed, 17 Nov 2010 17:36:21 +0100 Colomban Wendling <lists....@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/
pgpVGjTvAL2F0.pgp
Description: PGP signature
_______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel