My Ideas on Compositors

[Joakim Sindholt]

On Mon, 2011-01-31 at 20:32 +0100, Carl-Philip Haensch wrote:
> Hi,
> 
> after a discussion on #wayland, I want to write down some ideas about  
> compositor plugins for wayland at all.
> 
> At first, the wayland reference implementation should be as basic as  
> possible to make wayland also a choice for OpenBox users. On the other  
> hand, you want to have nice effects on your screen, wobbling windows  
> etc.
> 
> So the solution would be a plugin architecture that extends the  
> compositor for effects, app switchers and so on.
> My idea is a shared library that is loaded by wayland and that has a  
> bunch of callbacks wayland can call.
> There will be only one .so file loaded into wayland but that's no  
> reason to not implement plugin multiplexers and other interesting stuff.
> 
> So what we need to design is a plugin API that lets you do everything  
> you want. The compositor will have a list of procedure variables  
> containing the linked callbacks of the master plugin. Each function  
> call will be done if the pointer to the callback is not null. If the  
> plugin replaces something (for example drawing a surface), the  
> "native" implementation is not executed if there is a plugin function  
> for it.
> Now a list of functions that will have to be in the plugin API. Please  
> read through it and add things I forgot:
>   - onDrawBackground (draws the back image)
>   - onAfterDrawBackground(for background animations, panels)
>   - onSurfaceUpdate (to manipulate the position matrix of the window,  
> called after you have matrix and matrix_inv)
>   - onSurfaceDraw (replaces the draw code of the display.. for  
> wobbling windows)
>   - onAfterDraw (to draw notifications)
>   - onSurfaceCreate
>   - onSurfaceDelete
>   - onKeyPress (to fish out global hot keys like Alt+Tab; maybe needs  
> events like up/down/press)
>   - Functions to manipulate the visibility of the surfaces
>   - Functions to request meta data from surfaces (fullscreen,  
> maximized, minimized, toolbox)
>   - Functions to set size and position
> 
> So the following things are possible with this plugin API:
>   - Having a clock and CPU load applets in background
>   - Multiple desktops
>   - desktop overview
>   - desktop cube
>   - whobbling windows
>   - notifications
>   - panels and window placement around the panel
>   - app switcher
>   - properly workigng fullscreen
> 
> What did I forget? What do you think about the idea or the concept of  
> implementing it?

What benefit does this approach give over clayland (or similar toolkit
backends)?