On 14-05-16 07:34 PM, Lex Trotman wrote:
Hi Guys,
Some general observations, irrespective of the implementation.
- 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.
- 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.
- 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.
- 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