On 18 November 2010 03:36, Colomban Wendling lists.ban@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 #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
Cheers Lex
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel