[Geany-Devel] My non-C plugin roadmap

[Thomas Martitz]

Am 30.03.2015 um 15:48 schrieb Colomban Wendling:
> Le 30/03/2015 00:17, Thomas Martitz a écrit :
>> Am 29.03.2015 um 19:17 schrieb Colomban Wendling:
>>> Le 29/03/2015 00:23, Thomas Martitz a écrit :
>>>
>>>> - New API functions to allow plugins to act as proxy plugins (pluxies).
>>>> […]
>>> That's the part I'm really fuzzy about.  I really don't see why we need
>>> this specific layer […]
>> […]
>>
>> As with git master, Geany's core loader scans the plugin folder on
>> startup and on opening the PM dialog. For each recognized plugin file it
>> allocates a GeanyPluginPrivate and calls geany_load_module().
>>
>> […] with my new loader (no pluxies) it goes like this, and this is *very*
>> similar to git master.
>>
>> […]
> OK, fair enough indeed.  And well, proxy plugins are special enough to
> warrant their own API if it's useful anyway, so okay.

Yea, since the plan is to integrate the sub-plugins in the same UI as 
standard plugins, *some* kind of API is needed anyway. And I think my 
approach gives great flexibility to the pluxies while maintaining Geany 
(and the user) as the "supervisor". And this by only adding a single API 
function.

>
>> Now, with pluxies, it is completely the same except for:
>> 2* for each $file in $path, Geany calls is_plugin($file) which matches
>> additional file extensions (as provided by pluxies), it also calls the
>> probe() hook to resolve ambiguous files (e.g. .so files, they can be
>> core or libpeas plugins)
> As raised on IRC, one small question: do we need a file extension if we
> have probe()?  I don't mind much, but I would imagine probe() could
> filter extensions itself and simply return the appropriate value.  This
> would also potentially allow for extensionless plugins.
>
> But that's a small detail, and apart feeling it a little redundant I
> don't mind either way.

I think it's useful for a number of reasons:
- It's less duplicated code in the pluxies because virtually all of them 
need to have one or more file extension checks (even if it's just less 
than 10 lines)
- We could potentially give the user a more unified UI that sums up 
loaded pluxies
- Knowing the file extension in the core could become handy in the 
feature, like if we ever want to auto-activate pluxies for certain 
extensions (e.g. for pluxies that we ship with Geany itself), or 
reporting conflicting pluxies to the user. We wouldn't have to introduce 
a new API then
- Although very minor: we can safe the indirect function call into the 
pluxy if we already know the negative result

We could support extension-less sub-plugins either way (e.g. by treating 
the ""/NUL extension specially) so we're not limiting ourself. However 
it's true that it's not *strictly* needed.

>> I hope you better understand my concept now.  […]
> Yep, I do, thanks for these very good clarifications :)

You're welcome :)

Best regards