[Geany-Devel] RFC: Proxy plugins

Sat May 17 04:09:23 UTC 2014

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 at codebrainz.ca> wrote:
> 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.

Especially the new improved PM :)

I guess it just needs the effort to deprecate libpeas default UI and
incorporate it into Geany's.

>
>
>> 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.
>

That makes sense, especially if the libpeas GUI isn't going to be used (see 1.).

>
>> 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.

I thought you said on IRC it could be hidden under a <shudder> macro or two :)

>
>
>> 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" :)

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 at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel