Robert Carr
2007-02-26 18:16:17 UTC
Over time I believe it is clear that the composite manager will become
a standard piece of infastructure in the modern desktop, leveraged by
many applications, and integrated in to various parts of the desktop.
I believe this calls for a few things:
1. A parallel and well defined interface for plugins written for a
composite window manager. Essentially under this set up conforming
composite managers would define one mandatory, and one optional plugin
interface:
a.. Optional: Plugin interface working entirely as the specific
composite WM desires. Plugins working in this fashion would link
directly to the composite WM, access it's internal structures, all
that great stuff. Some plugins highly specific to the particular WM
or of large complexity would make sense under this interface.
b.. Mandatory: Plugin interface conforming to aforementioned standard
and well defined interface. Effectively this would require each
composite window manager to provide an implementation of the 'plugin
layer'. Each implementation would have the same API/ABI for plugins,
but have different code internally to work with it's particular window
manager.
Core <----> Standard Plugin layer <-----> Plugins
Core for each composite WM would load the particular WMs standard
plugin layer which would then load plugins written to the standard
layer.
This would enable full source and binary compatibility of a large
number of plugins between composite WMs, and I think this would really
be a great thing.
2. Standard Protocol for applications NOT linked (In terms of C
linkage) to the composite window manager to leverage the composite
manager for retained drawing. This would allow implementation of
things from
to a pager providing full previews of viewports, or thumbnails being
implemented at the taskbar level (For example the pager would queue up
a CompositeScreenToTexture request, and then a
DrawLastCompositedScreenAt request)
Essentially I would imagine each composite managers core would be able
to respond to the low level protocol , and composite managers could
write libraries on top of the protocol providing higher level
functions.
In regards to actual communication of the protocol I imagine a struct
in shared memory where requests are queued up.
A relatively small number of requests in the protocol could allow for
some very interesting effects.
One challenge I see is handling of damage, there would have to be some
sort of request to toggle the mode in which the composite manager
responds to damage.
I hope to make a post to both the Beryl and freedesktop mailing lists
soon outlining a more detailed draft of this.
The language in this post is rather rough as I wrote it quickly, but I
hope the points are clear.
Thanks,
Robert
a standard piece of infastructure in the modern desktop, leveraged by
many applications, and integrated in to various parts of the desktop.
I believe this calls for a few things:
1. A parallel and well defined interface for plugins written for a
composite window manager. Essentially under this set up conforming
composite managers would define one mandatory, and one optional plugin
interface:
a.. Optional: Plugin interface working entirely as the specific
composite WM desires. Plugins working in this fashion would link
directly to the composite WM, access it's internal structures, all
that great stuff. Some plugins highly specific to the particular WM
or of large complexity would make sense under this interface.
b.. Mandatory: Plugin interface conforming to aforementioned standard
and well defined interface. Effectively this would require each
composite window manager to provide an implementation of the 'plugin
layer'. Each implementation would have the same API/ABI for plugins,
but have different code internally to work with it's particular window
manager.
Core <----> Standard Plugin layer <-----> Plugins
Core for each composite WM would load the particular WMs standard
plugin layer which would then load plugins written to the standard
layer.
This would enable full source and binary compatibility of a large
number of plugins between composite WMs, and I think this would really
be a great thing.
2. Standard Protocol for applications NOT linked (In terms of C
linkage) to the composite window manager to leverage the composite
manager for retained drawing. This would allow implementation of
things from
to a pager providing full previews of viewports, or thumbnails being
implemented at the taskbar level (For example the pager would queue up
a CompositeScreenToTexture request, and then a
DrawLastCompositedScreenAt request)
Essentially I would imagine each composite managers core would be able
to respond to the low level protocol , and composite managers could
write libraries on top of the protocol providing higher level
functions.
In regards to actual communication of the protocol I imagine a struct
in shared memory where requests are queued up.
A relatively small number of requests in the protocol could allow for
some very interesting effects.
One challenge I see is handling of damage, there would have to be some
sort of request to toggle the mode in which the composite manager
responds to damage.
I hope to make a post to both the Beryl and freedesktop mailing lists
soon outlining a more detailed draft of this.
The language in this post is rather rough as I wrote it quickly, but I
hope the points are clear.
Thanks,
Robert