<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 21, 2014 at 3:06 PM, Marco Martin <span dir="ltr"><<a href="mailto:notmart@gmail.com" target="_blank">notmart@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is hopefully a synopsis of what has been said in the wayland planning<br>
meeting.<br>
<br>
If I got something wrong, please reply in the thread the correction ;)<br>
<br>
<br>
mgraesslin:<br>
* will give a talk on the current state at akademy<br>
* it probably does not make any sense to start working on other parts before<br>
at least the basics are ready in KWin<br>
* Weston as a development target will not give us much to work on Plasma<br>
<br>
plfiorini:<br>
* would like to write the plasmashell and test it in another compositor (not<br>
weston) at the same time you can wrok on kwin<br>
* is pushing for QtWayland release together with Qt 4.4, let's see if that<br>
happens<br>
<br>
Sho asks if couldn't we write a kwindowsystem backend that speaks xdg_shell to<br>
the compositor?<br>
<br>
Mgraesslin:<br>
wouldn't help, because xdg_shell is for taking with other windows - no need to<br>
have that in KWindowSystem as QtWayland needs to speak it.<br>
This is an implementation detail, and should not be public api.<br>
The idea is to get the Wayland backend into KWin and map all relevant<br>
information to an X11 window. Wayland windows would still be valid X11<br>
windows. Libtaskmanager would then still work and will make possible a step by<br>
step transition, and would allow to reuse a lot of current code in KWin.<br>
<br>
Also part of the same plan, libtaskmanager should be plugin based.  If we go<br>
that road we could implement the required plugin in libtaskmanager first<br>
without having to go all public directly.<br>
<br>
Discussion then gone a bit over Dialog: it needs to position itself with<br>
global coordinates and know the screen geometry. some changes in wayland, or<br>
the plasmashell->kwin protocol will need to allow global coordinates for<br>
windows.<br>
<br>
plfiorini: seems decision is leaning towards not having a system compositor.<br>
mgraesslin: kwin needs one:for 2 reasons: we can't have hardware specific code<br>
(like rendering on raspberry codepath) and kwin should not be privileged. So<br>
KWin may use the fullscreen shell of Weston as system compositor, different<br>
from the old concept of system compositor.<br>
<br>
mgraesslin: the wayland part of KWin will be quite standalone and isolated, so<br>
can be used as an integrated Wayland server, usable for integration tests<br>
<br>
Plasmashell relies heavily on KScreen that may pose a problem: it will need<br>
either to have KScreen supporting Wayland internally or to be ported again<br>
back to QScreen, needing QScreen to be fixed on both X11 and Wayland.<br>
<br>
Shadows should still have a protocol similar to now, to be painted by kwin and<br>
not by the window. In the same way output only windows should have a protocol<br>
for that instead of playing with masks, the general direction is to have<br>
protocols shell->kwin instead of windows working around problems.<br>
<br>
plfiorini says he may have a draft of the palsmashell->kwin protocol spec open<br>
for comment around middle of August.<br></blockquote><div><br></div><div>Regarding KScreen, it really should be ported, at the moment QScreen doesn't provide the information we need. I introduced one of the big missings for 5.4, which was screenRemoved, but we'll still need at least a primaryChanged signal.</div>

<div><br></div><div>Aleix</div></div></div></div>