[Geany-devel] geany-plugins depends on GIO

[Colomban Wendling]

Le 17/11/2010 01:03, Lex Trotman a écrit :
> On 17 November 2010 10:22, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>> Le 16/11/2010 23:32, Lex Trotman a écrit :
>>> On 17 November 2010 03:11, Frank Lanitz <frank at frank.uvena.de> wrote:
>>>> On Tue, 16 Nov 2010 15:13:03 +0100
>>>> Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>>>>
>>>>> Le 16/11/2010 09:23, Frank Lanitz a écrit :
>>>>>>
>>>>>> Well, agreed. In most cases it should work fine with compiled in
>>>>>> version number as most cases the API/ABI is changing with some
>>>>>> major release. But of course this will go into trouble with minor
>>>>>> releases as we had them with 0.19.1 or if anybody is remembering
>>>>>> the 10.x ones :)
>>>>>>
>>>>>> Well, however. I think a simple function which returns the version
>>>>>> string into plugin API would be enought or am I wrong? something
>>>>>> that is just doing a return GEANY_VERSION;
>>>>> I think it is better to return major, minor and micro version (or
>>>>> something that fits the versionning scheme) as plain integers.
>>>>> The advantage is that it becomes easy to use this version for any
>>>>> check, where a string is quite tedious to use.
>>>>>   geany_get_version(gint *major, gint *minor, gint *micro)
>>>>> for example, or 3 variables, not sure.
>>>>
>>>> Well, even it looks a bit dirty in my eyes (maybe we can put this into a
>>>> struct) it would solve users from use the parsing over and over again
>>>> as I did inside updatechecker with
>>>> static void parse_version_string(const gchar *ver, gint *major, gint
>>>> *minor, gint *micro, gchar **extra)
>>>>
>>>> So I'm pro ;)
>>>
>>>
>>> Just a question, shouldn't plugins be checking the ABI version was
>>> what they conpiled with not the Geany version?
>> I think this is not the question: Updatechecker wants to know the Geany
>> version to check whether there is a newer one, it's not a plugin
>> development need, but a goal.
> 
> Ah Ha!! I see, I'd missed the actual purpose of the plugin :-D
> 
> In that case I guess the three ints and some chars would be best for
> relative comparison, assuming thats how Geany is going to continue to
> do its versioning.
> 
>>
>> Of course, to check a functionality at runtime, a plugin should use the
>> API version (and then getting the Geany version is quite specific).
>>
>> BTW since you speak of this, I think API version should be made more
>> visible. The API version in which each function appeared should appear
>> in the doc rather than the Geany version it appeared in.
> 
> Agree.  But also "in which version did the functions parameters and/or
> semantics change" is more important.  If that change is newer than the
> plugin then the plugin shouldn't try to run.
I think that a simple update of the API version for this function is
good enough for this. And anyway, I think that the current API scheme of
Geany doesn't allow such changes without a function rename, so it would
probably never happen, would it?

> This would make
>> easier for plugin developers to know for which version check.
>> Also, perhaps a compile-time check would be interesting, it would allow
>> things like "if Geany version is too old for this, it's not fatal, we
>> will do without" -- stop me if it already exists.
> 
> The plugin only depends on the ABI it wants to use, so in a perfect
> world it would be able to check the each function it wants to call for
> the version in which it last changed.  This will allow plugins to
> continue to operate as long as possible without rebuilding.
> 
> At initialisation the plugin could simply present a list of functions
> and Geany could then return a list of versions for them (from a table
> extracted from the doc comments).  It is then up to the plugin to
> avoid functions it can't use, eg by not running at all or by limiting
> functionality to avoid using functions that are too new, too old or
> don't exist.
I think this is probably overkill, and would make the plugin development
really hard it it is a runtime check. Why? because you loose all the
compile-time safety that tells us if we use an undefined symbol, if it
isn't compatible and so on.
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.

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

My 2 cents,
Colomban