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

[Matthew Brush]

On 2016-08-30 06:29 AM, Colomban Wendling wrote:
> Le 29/08/2016 à 03:09, Matthew Brush a écrit :
>> On 2016-08-28 05:47 PM, Matthew Brush wrote:
>>> [...]
>>>
>>> To give an idea, the registration function called by plugins might look
>>> something like this:
>>>
>>>     gboolean ftplugin_register_provider(GeanyPlugin*,
>>>         GeanyFiletypeID, GeanyFiletypeFeature, GCallback, gpointer);
>>>
>>> [...]
>>
>> I forgot to mention, it may turn out that in order to provide a feature,
>> there may be a need for multiple callbacks (ex. activate, deactivate,
>> init_styles, prepare_list, whatever). If this ends up being the case, we
>> would need to either pass a table of callbacks here or perhaps a GObject
>> implementing a particular interface or whatever.
>
> Then probably better make the provide a structure like
>
> GeanyAutoCompleteProvider {
> 	GeanyFiletypeID filetype;
> 	GCallback feature1;
> 	...
> }

As long as it's uniform across all features (ie. all or none are using 
structs whether or not they have multiple features), that's pretty much 
what I had in mind, and is basically how I represented the internal 
tracking structures in my experimental code I was playing with.

API-wise I find it neater to keep the parameterization in the parameters 
list and keep any structures like that as simple vtables, but the 
difference is rather minute (probably whatever would work better for 
auto-binding generators to read).

>
> In theory I have nothing against GInterface, but I'm not quite sure it's
> a good idea to start riddling Geany with GObject API where we already
> have like 2 non-GObject-ish API styles (plugin registration, Proxy
> registration, signals…)
>
> Not saying GInterface is a presona non-grata, but that IMO it would have
> to prove very useful over the other solutions to be used.  Especially as
> people are likely to implement these filetype features in C or C++ more
> than Python, JavaScript or Ruby, so it should be comfortable in C and
> C++, and you know you don't like GObject boilerplate :)
>

I personally believe interfaces/abstract-bases to be the most 
appropriate technical solution (at least from OOP-languages) at our 
disposal, but I chose to stay away from that mostly to avoid the 
social/political/emotional ramifications of it on the discussion. 
Besides, re-implementing a small portion of it isn't that big a deal and 
doesn't feel so unnatural for C.

Cheers,
Matthew Brush