More on the subject of the internal implementation than the method of
communication, I believe a setup as follows for a drawing interface
makes sense:
Wrappable function:
grabDrawingRequests , this would allow for multiple methods of
communication and protocols to be implemented in plugins (such as over
a shared memory transport, dbus, text file, etc). grabDrawingRequests
would be called before the screen is painted. Plugins wrapping
grabDrawingRequests would be responsible for translating from their
method of communication to a format internal to the compositor (The
format inside the compositor could be relatively simple as there are
very few things required to set up complex drawings). Another function
such as
addDrawingRequest(CompDrawingRequest * dr) would likely be added as a
utility for plugins to add the resulting internal format drawing
request to a linked list.
Core would be responsible for doing the actual painting at appropriate
points during screen painting.
It also seems reasonable to consider the idea of a wrappable
handleDrawingRequest function but this seems like it is not desirable.
Plugins would be required to identify whether they wanted to handle
the request based on some flag in a structure, this would become a
mess to handle and in the long run probably be less extensible.
I'm out of town until Sunday but should be able to get some code
working for this next week.
Regards,
Robert
_______________________________________________
beryl-dev mailing list
beryl-dev@lists.beryl-project.org
http://lists.beryl-project.org/mailman/listinfo/beryl-dev
