[Geany-Devel] [FT-plugins] Proposed Design

[Lex Trotman]

On 29 August 2016 at 12:30, Matthew Brush <mbrush at codebrainz.ca> wrote:
> On 2016-08-28 06:59 PM, Lex Trotman wrote:
>>
>> On 29 August 2016 at 10:47, Matthew Brush <mbrush at codebrainz.ca> wrote:
>>>
>>> [...]
>>>
>>> "Registration" - the act (ie. function call) of an ft-plugin declaring
>>> its
>>> interest in providing a feature for a filetype. An ft-plugin can register
>>> to
>>> provide one or more features for one or more filetypes.
>>
>>
>> I think the registration data should go in the plugin data file that
>> Thomas added, not require plugins to be loaded to register, otherwise
>> all language plugins will be loaded at all times just so they can call
>> the function to be registered.
>>
>
> That's a thought. I think the plugin data file you refer to may only be for
> the libpeas proxy plugin which is not part of Geany (yet).
>
> IIUC, at least when the plugin manager is opened, Geany loads all of the
> plugin DLLs anyway. Plugins could register their providers at
> `geany_load_module()`-time before they're actually initialized. Needs more
> consideration.

Ok, as noted below, may need to be a separate mechanism anyway.

[...]
>>>
>>> The order of the list of plugins registered to provide a feature for a
>>> given
>>> feature/filetype pair would determine the priority given when Geany asks
>>> the
>>> provider to perform its function. The callback functions could return a
>>> boolean telling Geany whether the provider performed its function or
>>> whether
>>> it should try the next provider in the list, similar to many GTK+
>>> callbacks.
>>> If no provider performs its function, or there are no providers
>>> registered
>>> for a given feature/filetype, then Geany would take its existing code
>>> path
>>> to provide the feature itself.
>>
>>
>> This makes sense, but so does Colombans desire for plugins to be able
>> to improve on the work of other plugins so you don't have to have all
>> plugins re-implement the basic functionality.  Not immediately sure
>> how to reconcile these two options, unless Colombans desire is
>> provided by having the dependent plugin have to call the basic plugin
>> function directly, so its not Geany's problem.
>>
>
> That's the idea with boolean results, a plugin could actually provide the
> feature but return `FALSE` and Geany would call the next provider to perform
> the feature as well. It's kind of like a poor-man's inheritance.

Actually, after more thought it doesn't make sense to me.

If a more specific provider wants to build on a more general one, it
wants the general one to run before it, so it has to be ordered after
the general provider, which has to return FALSE to allow the more
specific one to run.  But if the more specific provider isn't loaded
the general provider has to return TRUE to stop the geany built-in
functionality from running.  This means the general provider has to
know about the specific providers and if they are loaded, which is the
wrong way around.

Also a more specific provider that does it all itself and doesn't want
the general one to muck stuff up has to be ordered before the general
one to return TRUE so the general one doesn't run.  So providers have
to be able to re-order themselves or to specify an order.

I think if a provider depends on another it should be ordered first
and directly call the other, then it can return TRUE so the other
isn't called twice.

And Geany should make its fallback functionality available to call, so
a provider that wants to just make a small adjustment doesn't have to
re-implement the default (right Colomban).  Or the Geany default can
be removed and added to core plugins :)

[...]
>>>
>>> To enable Geany to use the providers, in the existing code just before
>>> it's
>>> about to provide the feature itself as it does now, we could insert a
>>> check/call to try the ft-plugin providers.
>>
>>
>> This may require some unwinding of the spaghetti to clearly identify
>> the beginning of a "feature" and ensure it happens in one place.  Some
>> places there is stuff split between different callbacks depending on
>> how the feature was triggered.
>>
>
> Most likely yeah. In some cases though, it might be as simple as sticking an
> "if" statement at the beginning of a single function with an early return.

Yes, thats where we want to get to, but I suspect that its not allways
the reality now.  Untangling spaghetti is a GOOD thing, its just more
work :)

[...]
>>
>> What is missing is how the FT plugins get loaded in the first place so
>> they can register, if the user can control that from the PM GUI, or if
>> these plugins are controlled from your GUI only (my preference).  If
>> the FT plugins are loaded via a different path and don't appear in the
>> PM that may solve the order issue as well.
>>
>
> At least initially, I think when the plugins are activated they could
> register their providers. The user would just check the plugin in the plugin
> manager dialog as usual. In the future it could be at
> `geany_load_module()`-time, some separate GUI, or a plugin data file,
> statically as you mentioned above. It could even be done using the
> filetype.* configuration files. IMO, we should start with what's as simple
> as possible to perform the function.
>

Certainly during development the existing plugin system could be used,
there won't be many FT plugins then anyway.

But before release on the unsuspecting world a better UI is probably needed.

In PM the plugins are ordered alphabetically, and thats the order the
user is likely to enable them in, but given the requirements for
ordering stuff noted above, that might not be right.  Result, one
confused user.

Its important to encourage correct usage because the enabling UI is
the first thing a user is going to see when they turn on the new
feature.  Automatic dependency and ordering management may be needed.

Cheers
Lex

> Cheers,
> Matthew Brush
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel