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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
