Note: Sorry for the shalls, I have been reading too many specifications lately and it has worked its way into my brain.
On 17 May 2014 13:04, Matthew Brush mbrush@codebrainz.ca wrote:
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.
Especially the new improved PM :)
I guess it just needs the effort to deprecate libpeas default UI and incorporate it into Geany's.
- 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.
That makes sense, especially if the libpeas GUI isn't going to be used (see 1.).
- 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.
I thought you said on IRC it could be hidden under a <shudder> macro or two :)
- 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" :)
That means we have decided on an implementation, before any is complete and the full implications are known.
That is not a good way to do something as complex as this. As an example I would point out the misunderstanding already discussed on IRC of how much libpeas actually contributed to the bindings. There will surely be more misunderstandings/lack of knowledge that makes deciding at this point a bad approach.
Certainly if it becomes clear that one approach is markedly superior to the other, and is actually likely to be fully implementable, then its ok to commit a partly working (or even non-working) implementation of new stuff that doesn't break existing functionality.
But we are not at that point yet. So the discussion is how to get to that point.
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.
Well, yes, developing it in codebrainz/geany or kugel/geany is unlikely to see it have much adult supervision. :)
Since the switch to git we have not had any long running branches, even though it supports them just fine, in fact the last was probably the build system changes back under SVN. The big advantage of branches under the main repository is that they will let *all* the devs know what you are doing, even if they don't want to know. So there can be input to the process. That was very useful to the build system, even if some of the changes did cause Enrico a heart attack. At least he could then object immediately, not at the end when 1000 more commits depended on the contentious ones.
As you say massive commit bombs from personal forks is a bad approach both technically and socially. Technically its hard to review and understand possible implications of a big change and the developer, having thought about it a lot, has a mental model that none of the reviewers have, and socially the developer has by then got so much personal investment in it, that its hard to respond to criticisms objectively.
That problem is not unique to Geany, the same technical problem occurs even with the Kernel when some company drops in a whole new driver or something, and they have many more resources than we do. But things like new schedulers or other big changes internal to the kernel must progress through long-term branches before being included in the mainline.
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).
Well, all of those have been personal development commit-bombs.
To be fair, document-messages is waiting on a GTK version hike, precisely because it *has not* got lots of #ifdefs to turn it off on 2.16. Why we can't manage to make the GTK jump is not relevant to this discussion.
Splitwindow2 did have some testing during development, and I am happy to have it committed, but Colomban has expressed reservations for the above mentioned technical reasons IIRC.
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel