[Geany-Devel] RFC: Proxy plugins

[Matthew Brush]

On 14-05-16 07:34 PM, Lex Trotman wrote:
> Hi Guys,
>
> Some general observations, irrespective of the implementation.
>
> 1. There shall be only one plugin control GUI.  The users don't care
> how a plugin is implemented, or what language its in, they just want
> to use it.  Having to look in two places will often mean one group of
> plugins is missed.  Thats also one of the complaints against the
> current Geanypy implementation.
>

+1  I think this is quite important, and if anyone has used the builtin 
Peas plugin manager UI (as in my peas* branches for testing purposes) 
they'd probably agree Geany's Plugin Manager is a fair bit nicer. I'm 
pretty sure this wouldn't be too hard either, as peas provides much the 
same metadata/concepts as is needed for Geany's PM.

> 2. All current plugins shall continue to work for a considerable
> period until any new mechanism is in place.  Re-compilation is
> acceptable although maintaining ABI is preferable.  It has taken so
> long to accumulate a set of fairly useful plugins that we can't afford
> to try to force them to be re-built (quickly) to a new interface to
> keep working.
>

+1 This is why I don't think we should try and munge the existing 
working C loader into a Peas duplicate and instead use a pre-written one 
that is used in production, as a parallel/alternative to what exists now.

> 3. Any new plugin system shall not require large amounts of
> boilerplate to write a plugin, in any language.  The basic point of
> this effort is to encourage plugins by making it easier.  Hiding
> boilerplate under a part of the bindings is of course acceptable.
>

+1 C is the only likely suspect, implementing a GObject interface isn't 
exactly the most brief code to write (but it is at least well structured 
and easy to read). I'm pretty sure some fairly compatible adapter could 
be implemented, the GeanyWinCmd interface in my experimental peas* 
branches is quite similar semantically to the existing plugin 
interface's plugin_init/plugin_deinit, in practice.

> 4. A full implementation is required before anything is added to
> Geany, that includes bindings to all the Geany API for the existing
> languages (C/C++/Vala/Python).  Finding unexpected difficulties with
> the bindings is so likely (see Geanypy keybindings issues) that there
> needs to be a clear demonstration that they can be addressed.
>

-1 This will be dead-on-arrival for any implementation. I would agree if 
you had said "... before the --enable-alternative-build-option configure 
flag became the default/defaulted to on" :)

We just aren't setup to maintain a long running disparate branch like 
this that nobody could humanly review and for sure most people won't 
test, for final merging into core in some giant commit-bomb designed by 
one person in their own private/local repository. IMO, we just need to 
do like we do with --enable-gtk3 configure flag so that the default 
options don't enable anything provisional/experimental.

To be clear, I don't mean to imply that we should commit random buggy 
code (like my peas* branches at present) into the core, just that it's 
too large of a thing not to be worked on in the master development 
branch by all developers/stakeholders, gradually. By experience we've 
proven that to do otherwise is anywhere from hard (see GtkBuilder 
changes), to pointlessly discouraging (see document-messages), to 
completely impractical to merge into core at the end (see splitwindow2 
and any other pending non-trivial core code changes in recent history).

Cheers,
Matthew Brush