My first thought was to use GTK signals, its probably not appropriate to have a signal for each feature for each language, but it is possible for there to be one signal per feature and the plugin callbacks then need to check the filetype of the current document and return false if its not one they handle, so the next plugin callback can be invoked

Signals are a good start, but maybe too heavy-weight for the purpose.

I'd rather like to see interfaces (GObject-based) to be used. They are as powerful (if not more, since you can attach data with instances), but also allow for potential adoption of libpeas (in a future far away) which uses interfaces as natural extension points.

In some way, libpeas solves already exactly what we want here: plugins can extend or replace core functionality by implementing interfaces, which are registered in the core application and then instantiated when necessary. Because of this, our design should be compatible with that.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.