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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel