Wow, what a week! It’s just great to be at Desktop Summit again and meeting all those KDE people again and also the GNOME people which gives the event a different and pleasant touch.
The big topic for me at this Desktop Summit is to lay out the foundations for bringing the KDE Plasma Workspaces from the X11 Windowing System to the upcoming Wayland windowing system. This is an effort which will most likely take years, nevertheless I am hoping that we find enough interested developers to have something ready as a developer preview in our next release. The complete plan has been outlined in my presentation here at Desktop Summit. It seems like my slides and video recordings are not yet uploaded, but I put my slides in our wiki. If you can read German you can also have a look at my article in the current issue of freiesMagazin, where I wrote down what I talked about.
As there was some media coverage about my talk and also about other changes in KDE which are completely unrelated I just want to point out that the work going on for KDE Frameworks 5 does not influence our development of the desktop at all. This means we will continue to release further 4.x releases of the KDE Plasma Workspaces. Also given the changes which are going to happen in KDE Frameworks it will not be disruptive to the desktop. This means that there is no reason to use a “5.0” release to switch the windowing system from X11 to Wayland. We will switch when we are confident that we do not break the users’ desktops.
I also read some concerns about that we would remove the X11 Network Transparency. Relax: we don’t want to break our users’ desktops. Just have a look at this architecture:
As you can see even with Wayland as the windowing system we will continue to support remote X Clients.
Yesterday we had a BoF about the changes needed for Plasma. We did unfortunately not agree on that much, but I will put up a wiki page with small TODOs, so that others can work on it. The BoF turned out into a discussion about Client Side Windowdecorations, which I did not want to spend time on. But in the end I think it was useful as now developers from other projects understand our position better and can understand why we will stick to server side decorations even with Wayland. I will soon write down a policy to exactly specify when windows will be decorated and when not and implement it for 4.8 (should only require minor changes).
On a completely unrelated note: thanks to the decision of three persons, I will be going to Akademy 2012. Thanks very much for the award.
=-=-=-=-=
Powered by Blogilo
Hello, I have several questions:
1) X has a ‘MIT-SHM shared main memory’ extension, would it be possible to have a similar ‘shared GPU memory’ extension?
IMHO this would give nearly the same performance as Wayland, with much less new code..
2) from a security POV, is one is better than the other?
I was thinking about one “spying” application which draw an invisible window and receives all the input events: it seemed a risk with Wayland but maybe not as you don’t plan to use client-side decoration..
3) a strange criticism in your presentation is that “X is old” (*) but AFAIK Qt is still using Xlib instead of XCB! So Qt developers are using an old part of X even though it has a newer replacement, forcing the X developers to keep providing Xlib..
It’s very nice to learn that you plan to use server side decorations, “This application is not responding, force quit?” isn’t coming to KDE!
*: vi and emacs are old too, yet they’re still powerful and useful.
Does “server side decoration” also mean that it won’t be possible to theme the deco from the app?
Why would the application want to theme the decoration? The theme is applied by the widget style which is in case of KDE Oxygen which also controls the decoration. At the moment the application already influences the look of the decoration. So as you can see this is already possible.
>Why would the application want to theme the decoration?
There are cases where the application want to use a different style or color scheme. Digikam is an example for the need of a different color scheme, Dragon Player 3 with its own style, for the need of a possibility to use its own style in the deco. Both applications designs is broken as it is.
I hope with Qt5 it will be easier for the applications to use a different widget style (apps which use its own widget creations should use a own style), but those will need also to style the deco.
Digikam is an example for how not to do it. And concerning Dragon Player 3, I think I talked to Harald about the general issues and he did not complain.
Everyone knows you plan to support running an X11 server on wayland.
But if KDE applications use wayland directly, how can you run those applications over the network?
That’s the issue I’m worried about – if Gtk and Qt stop supporting X11, or it becomes a 2nd class citizen and non-standard configuration, then network transparency will, for all intents and purposes, be dead.
As long as there are people who need X11 I’m sure there is someone maintaining the Qt Lighthouse Plugin for X11.
I think you miss the point.
If GTK and Qt stop supporting X and new applications are Wayland only then I loose network transparency for those apps.
It’s not X that I need, but network transparency. Without that, Wayland for me is dead.
Qt has multiple backends called “Lighthouse”. Thanks to the Lighthouse ports it is possible to run a Qt application on X11, Wayland, Android, $Whatever without adjusting the code. As long as there is a lighthouse port to X11 even new written applications will just work on X11 – even if the remote system uses Wayland as windowing system.
@renoX: KDE actually has had “This application is not responding, force quit?” for many years.
@Eike Hein: only when you close it to warn you that there is an issue, you can still iconify an unresponsive application which isn’t the case with client-side decoration.
good point… i always preferred kde’s behavior in that situation.. didn’t know the exact reason though..
The window manager (IMHO) should be running in a separate thread or process, regardless of your decision to use client or server-side decorations. If that is the case, then you should still have control of the application’s window (even if you can’t control the app).
The means by which you reach that end may or may not be simple or easy. 😉
> This means we will continue to release further 4.x releases of the KDE Plasma Workspaces.
But what about libplasma? I worked hard implementing PackageKit integration in libplasma, and now I’m told that there are no plans to do a kdelibs 4.8 and that everything will have to wait for 5.0, which just sabotages my work. 🙁
why didn’t you work on libplasma2 directly? It had already been around for months and will probably be used before there is the 5.0 release.
@Martin: Kevin is a Fedora guy, so they’re mainly interested in Plasma Desktop, which isn’t going to use libplasma2 afaik.
libplasma2 will also be used in the desktop. Maybe not as fast as in active, but it is planned.
IMHO, libplasma2 in plasma-desktop can only possibly be 5.0 material. Trying to load both libplasma 1 and libplasma2 into the same process is extremely unlikely to work.
hey, thanks for the talk, where can we find the video (when its online)?
I will blog about it.