This allows plugins to detect the API version of Geany at runtime. This enables switching behavior based on the API version (perhaps using a new feature with a fallback for older API versions). Previously the only alternatives were to hard-depend on a more recent Geany version or ignoring new features. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1406
-- Commit Summary --
* api: new function geany_api_version
-- File Changes --
M src/plugindata.h (2) M src/pluginutils.c (9) M src/pluginutils.h (1)
-- Patch Links --
https://github.com/geany/geany/pull/1406.patch https://github.com/geany/geany/pull/1406.diff
@b4n @codebrainz @elextr This is a trivial change and doesn't affect l10n, so I'd like this for 1.29.
I mean 1.30 of course
Agree with the use-case.
If its in the API shouldn't it be marked `GEANY_API_SYMBOL` ?
b4n requested changes on this pull request.
OK, why not, although I don't really see so much use case for C plugins: such checks only allow to guard dynamic features, and the only one I can think of would be `GeanyObject` signals. But it sounds reasonable, so OK I guess.
@@ -52,6 +52,15 @@ typedef struct
PluginDocDataProxy;
+/** Returns the runtime API version Geany was compiled with. + * + * @return Geany's API version + */ +gint geany_api_version(void)
@elextr is right it lacks `GEANY_API_SYMBOL`
kugel- commented on this pull request.
@@ -52,6 +52,15 @@ typedef struct
PluginDocDataProxy;
+/** Returns the runtime API version Geany was compiled with. + * + * @return Geany's API version + */ +gint geany_api_version(void)
Indeed, sorry.
If/when we merge #1236 I'd still like peasy to load on 1.30, that's my main motivation.
If/when we merge #1236 I'd still like peasy to load on 1.30, that's my main motivation.
Fair enough. Though this technically breaks API as mentioned there, so we could argue on bumping ABI (as it's the closets thing we have to "broken backward compat")
@b4n, surely adding to API and incrementing the number is the intended method?
Don't the plugins test against >= API number and exactly == ABI number?
Any plugin that uses this function will need to ask for API >= the number where this was introduced.
@elextr I don't get what point you're tying to make? Mine was that Geany's C API is basically only made of compile-time things (functions, structure fields, etc.), so there's no point in checking those at runtime: either it built and linked in which case you're all set, or it didn't and this API won't help. *Maybe* with lazy loading you could build against a newer Geany (so it finds the new symbols at build time) and load against an older one if you guarded the calls so they aren't ever actually reached, but this seems highly fragile to me if at all workable.
b4n approved this pull request.
Otherwise LGTM
@@ -52,6 +52,16 @@ typedef struct
PluginDocDataProxy;
+/** Returns the runtime API version Geany was compiled with. + * + * @return Geany's API version
Maybe add more detailed docs, like "this can be used to [blah blah what is it useful for] at runtime"? @elextr !!!
@b4n, I thought you were saying this change invalidated the ABI.
In terms of its use-case, isn't the whole point of the GIR stuff @kugel- is doing to allow dynamic binding from languages like Python or Js without the compiled hand carved bindings? So that dynamically bound code needs to be able to check whats available to it.
codebrainz commented on this pull request.
@@ -52,6 +52,16 @@ typedef struct
PluginDocDataProxy;
+/** Returns the runtime API version Geany was compiled with. + * + * @return Geany's API version
You could also take the docs from [my original PR](https://github.com/kugel-/geany/pull/3) ([this commit](https://github.com/kugel-/geany/pull/3/commits/d829a2f42889b1cb059cb0db02d80...)).
b4n commented on this pull request.
@@ -52,6 +52,16 @@ typedef struct
PluginDocDataProxy;
+/** Returns the runtime API version Geany was compiled with. + * + * @return Geany's API version
@codebrainz indeed, looks nice :) (I knew we already mentioned something like that! I wasn't crazy -- not about that, at least)
In terms of its use-case, isn't the whole point of the GIR stuff @kugel- is doing to allow dynamic binding from languages like Python or Js without the compiled hand carved bindings? So that dynamically bound code needs to be able to check whats available to it.
Sure, but if there's no use case for the C API, wouldn't it be better as a GI/Peasy thing? But anyway, as said in theory it's nice, so if we add some dynamic stuff in the future it can be useful then.
Peasy doesn't want to provide much of an API on its own, except where it makes using Geany's APIs easier or more natural for the actual language.
And it couldn't be a "peasy thing", since peasy (using the C api) has to have a way to get the API version itself.
Updated with more text inspired by @codebrainz and added a proper @since tag.
@b4n Please merge.
or @codebrainz :-)
Merged #1406.
github-comments@lists.geany.org