[compiz] Plugin Library Interface

[David Reveman]

On Wed, 2007-03-07 at 14:28 +0100, Patrick Niklaus wrote: 
> Hi,
> 
> some of you might noticed that there was recently some discussion on
> the Beryl ML about an interface which provides sharing functions and
> allows us to do library plugins. One example for this kind of plugins
> is text, which was recently ported to that system. I now want to
> explain here how it works in general.
> 
> Core does save the shared library functions in a CompLibraryFunction struct:
> struct _CompLibraryFunction {
> 	CompLibraryFunction *prev;
> 	CompLibraryFunction *next;
> 
> 	char *name;
> 	void *function;
> };
> 
> Core also gets a number of utility functions:
> 
> void addLibraryFunction (CompDisplay *d, char *name, void *function);
> void removeLibraryFunction (CompDisplay *d, char *name);
> void* getLibraryFunction (CompDisplay *d, char* name);
> void updateLibraryFunction(CompDisplay *d, CompLibraryFunction *func);
> 
> You can register a function through addLibraryFunction and remove it
> with removeLibraryFunction.
> Whenever a function gets added or removed updateLibraryFunction is
> called. Like initScreen/finiScreen it's done through a additional
> entry in the vTable. It doesn't make sense to make this function
> wrap-able, it's just too important and no plugin should be able to
> stop or manipulate it.
> 
> Plugins which need a shared function can get it through
> getLibraryFunction, most likely you will call that in initDisplay and
> just save the pointer to the function.
> 
> When you want to see how exactly it's used in plugins you can have a
> look at text-plugin, which is in beryl-plugins at trunk
> (http://bugs.beryl-project.org/browser/trunk/beryl-plugins/src/text.c).
> 
> We just want to get some feedback on these ideas. If you are
> interested I can provide a patch for compiz too.

Hey Patrick,

Thanks for your explanation. I don't know if this is a good idea or not.

Most of the interface we have on the core so far have specific needs and
I'm sure future interfaces will too. This library interface would have
to be extended to support cases like that. If we do that, then this
would work as a low level interface that other interfaces can be layered
on top of and plugins can create their own interfaces, which could make
sense but I'm not sure.

Anyhow, I'm not against this in it's current state even though it seems
an awful lot like just providing dynamic library loading which it makes
more sense to do using dlopen, dlsym...

If we have a case where this interface makes more sense than anything
else then fine with including it.

The text_to_pixmap interface is very specific and I don't think the
functionality itself is a good idea. What are the use cases for this?
For rendering text, I suggest that we create an interface that hooks
into the drawing framework and allow plugins to implement glyph caching
similar to what I once created for xgl and cairo's glitz backend.

Do you have other use cases for which this library interface fit in?

- David