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.
Regards,
Patrick
Patrick Niklaus wrote:> We just want to get some feedback on these ideas. If you are > interested I can provide a patch for compiz too.Thanks for showing us this. I have a couple of questions though. What are the major pros/cons of using this method over plain old libraries? Do you have any other library plugins other than text? Or what do you plan for other types of library plugin? It seems like only text and group use this at the moment.
2007/3/7, Mike Dransfield <mike@blueroot.co.uk>:> > It could also be disabled with an option, or at compile time. > > If it was a really big library then you could use dlopen, but this > is just one function. >Doing it through an option would be a real mess in the settings manager and just removing it at compile time would mean code becoming very growed with defines.> > I do not think that such tight coupling of plugins will lead > to a stable system. The plugins should be unaware of each > other as much as possible. I do not see an awful lot of benefits > over standard linking methods. Adding a versioning scheme just > sounds like you are reinventing the wheel. >Adding a versioning system isn't that hard in this case. Just storing the size of the typedef containing the functions information should be enough.> > There is incompatibility between compiz and beryl. All that > needs to be done is rip the textToPixmap function from text > and add it to whatever plugin you want to draw text. It provides > the same functionality with very little overhead. Then all the extra > functions you have added will be removed. Will the user be able to > notice a difference? >Thats why I said I would provide a patch for Compiz as well. Are you really saying code duplication is good? If the user could tell the difference isn't relevant here, but it's much harder to maintain code of you have copies of it in 4 source files. Making every plugin that wants to draw text depending from pango is another bad thing.> > All you seem to have here is a beryl specific dynamic library > loader. If dlopen is too hard, then couldn't you write wrappers > to make that easier? That way everyone could benefit from your > hard work. >See my answer above.> > This would make sense if you wanted to add textToPixmap > to core and then use different plugins to wrap it, in the same > way as the image plugins do now. But this is not what you are > proposing. Maybe that could solve your particular text problem > better? >I thought core should be kept as small and simple as possible? Regards, Patrick
Except from the notifications on Load/Unload it does not offer anything but another framework to load dlls at runtime. I fail to see any real benefit ___________________________________________________________ ?????????????? Yahoo!; ?????????? ?? ?????????? ???????? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? http://login.yahoo.com/config/mail?.intl=gr
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