Hi,
Recently there was some talk about adding support in core for library plugins.
Unfortunatily, the conversation was terminated before a decision was made.
Library Plugins Interface allow you to share functions between different plugins.
Basically, there is a function in core (which gets a name and function pointer) for sharing a plugin function, a function for removing that shared function, and another function for getting that shared function.
The function-pointers are stored in a linked list.
When a plugin adds or unloads a shared function, there is an update notify (which is a new vtable entry).
Plugins save the pointers of the shared functions they need at startup and update them when they get the update notify.
The advantages of this system are:
1. Removing of code duplication.
2. More consistent behaviour.
3. Different implementations can be done as different library plugins. The plugin using the shared function(s) won't care which implementation is used. Example: a text drawing plugin could be done in both pango and qt.
4. Update notifications make it easier to follow pointer changes.
Another big advantage of library plugins is that they can store their own data for screens / displays / windows, they can wrap functions and have options like any other plugin, and unlike using just plain shared-libraries.
An example why using this interface is better than using shared libraries:
- Glow plugin - we share a function called addGlow(w, color). In this function we will save the information inside the GlowWindow struct. Glow plugin will wrap drawWindow and paint the glow itself.
Now each plugin that wants to use glow will just need to store a function pointer to addGlow, call it when it wants to add glow, and the rest is automatically done by glow-plugin.
With the glow example there will be no dependecy, glow is unloaded - no glow.
In different occasions there might be dependencies, for example, a plugin like thumbnail could use a library plugin that can paint hidden windows (switcher can also use this library, and many other plugins too). Such a library plugin can be cleanely done with input-redirection, but in the mean-time (input redirection isn't avaialble in all distros ATM), other solutions are possible: using XShape, or just saving a snapshot of the window before it gets minimized. Even when input-redirection will be available at all the distributions, i don't think adding such an interface for core is necessary if it can be done cleanely inside a plugin.
In my opinion, this system can give a better solution than adding new plugin-specific-interfaces in core all the time, and this way plugins can add their own interfaces for things that are too plugin-specific for core.