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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
