[Geany-Devel] RFC: Proxy plugins
mbrush at xxxxx
Sat May 17 03:04:26 UTC 2014
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).
More information about the Devel