On Mon, Jul 21, 2014 at 3:06 PM, Marco Martin <notm...@gmail.com> wrote:
> 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. > 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. Aleix
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel