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

[Matthew Brush]

On 2016-08-28 08:17 PM, Lex Trotman wrote:
> On 29 August 2016 at 12:30, Matthew Brush <mbrush at codebrainz.ca> wrote:
>> [...]
>>
>> 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.
>

It's a good point. I think at first just using the activation and manual 
user-customized order will likely suffice. I expect the common case to 
be activating a single plugin (ex. my CDK plugin) to cover a set of 
features/filetypes and no other plugins conflicting or dependent. In the 
future it will probably be useful to make this more automatic by adding 
some kind of inter-plugin dependency manager and GUIs whatnot.

Cheers,
Matthew Brush