Wayland plasnning meeting notes

[Marco Martin]

This is hopefully a synopsis of what has been said in the wayland planning 
meeting.

If I got something wrong, please reply in the thread the correction ;)


mgraesslin:
* will give a talk on the current state at akademy
* it probably does not make any sense to start working on other parts before 
at least the basics are ready in KWin
* Weston as a development target will not give us much to work on Plasma

plfiorini:
* would like to write the plasmashell and test it in another compositor (not 
weston) at the same time you can wrok on kwin
* is pushing for QtWayland release together with Qt 4.4, let's see if that 
happens

Sho asks if couldn't we write a kwindowsystem backend that speaks xdg_shell to 
the compositor?

Mgraesslin:
wouldn't help, because xdg_shell is for taking with other windows - no need to 
have that in KWindowSystem as QtWayland needs to speak it.
This is an implementation detail, and should not be public api.
The idea is to get the Wayland backend into KWin and map all relevant 
information to an X11 window. Wayland windows would still be valid X11 
windows. Libtaskmanager would then still work and will make possible a step by 
step transition, and would allow to reuse a lot of current code in KWin.

Also part of the same plan, libtaskmanager should be plugin based.  If we go 
that road we could implement the required plugin in libtaskmanager first 
without having to go all public directly.

Discussion then gone a bit over Dialog: it needs to position itself with 
global coordinates and know the screen geometry. some changes in wayland, or 
the plasmashell->kwin protocol will need to allow global coordinates for 
windows.

plfiorini: seems decision is leaning towards not having a system compositor.
mgraesslin: kwin needs one:for 2 reasons: we can't have hardware specific code 
(like rendering on raspberry codepath) and kwin should not be privileged. So 
KWin may use the fullscreen shell of Weston as system compositor, different 
from the old concept of system compositor.

mgraesslin: the wayland part of KWin will be quite standalone and isolated, so 
can be used as an integrated Wayland server, usable for integration tests

Plasmashell relies heavily on KScreen that may pose a problem: it will need 
either to have KScreen supporting Wayland internally or to be ported again 
back to QScreen, needing QScreen to be fixed on both X11 and Wayland.

Shadows should still have a protocol similar to now, to be painted by kwin and 
not by the window. In the same way output only windows should have a protocol 
for that instead of playing with masks, the general direction is to have 
protocols shell->kwin instead of windows working around problems.

plfiorini says he may have a draft of the palsmashell->kwin protocol spec open 
for comment around middle of August.


-- 
Marco Martin