Yesterday during the Tokamak 6 sprint in Nuremberg we discussed the role of KWin in Plasma Workspaces 2. At the moment in Plasma Workspaces 1 KWin is of course the recommended window manager and compositor, but it’s also possible to use a different window manager. Back in the days there were quite a lot of users who run Plasma with Compiz. In theory that shouldn’t matter because everything is standardized with EWMH and ICCCM. Over the years we added more and more extensions to EWMH. It’s all open source so anyone can implement these extensions (Compiz used to do so), nevertheless right now there is probably no other window manager available to offer the full experience except KWin.
Plasma Workspaces 2 will be released at an interesting point of time. We don’t want to do the transition to Qt 5 and Wayland at the same time, so it will still be X based. But we all agree that our future will be on Wayland and even if we use X as the windowing system our primary focus is on Wayland. With Wayland quite a few things will change. KWin will play a more important role as it will be the Wayland compositor – we do not plan to use Weston.
Given that we know that the Wayland shell interface only covers part of what Plasma needs and some of our needs are extremely Plasma specific (for example Activities) it would be tempting to say that we tie KWin to Plasma. Let’s face it: which other compositor will be there to replace KWin? The reference compositor will probably never accept Plasma specific patches for things like Activities, Compiz won’t be ported to Wayland and GNOME Shell will probably never be a solution for Plasma. For the small window managers we do not know whether they will go to Wayland at all, but I expect rather not, though I expect that we will see Weston forks/extensions for substitutions of tiling window managers.
We decided to resist the temptation to go the easy road, but instead will develop all our integration bits in a way that one could replace KWin by a different Wayland compositor, even if that is just a theoretical option. Of course we will not do any fallback modes for the case that one is using e.g. Weston without Plasma integration bits. So the features which we need might then just be disabled. Adding fallback modes would most likely just result in bit rotting code as nobody would use it.
Of course to make it possible that others can provide compatibility features we need to properly document our extensions and additional interfaces. Luckily Wayland implicitly forces us to do so. The general plan is to publish our extensions and also try to standardize what makes sense to be standardized and we hope that this would also benefit other projects. What we especially had in mind is of course Razor-Qt which already supports using KWin. By properly documenting all our Plasma-KWin communication channel, they can also use what is useful to them and it ensures that we don’t break KWin in a way that it gets unusable for Razor-Qt.
Has there been any talk yet about a (rough) timeline for Plasma Workspaces 2 release dates? Will it still be released simultaneously with KDE SC? Perhaps 4.12 or 4.13?
talked about it, some ideas and agreed on “it’s done, when it’s done”
“Will it still be released simultaneously with KDE SC? ”
There is no intention to do so. If it happens, it will be coincidental, so I doubt it will happen.
Frameworks 5 will be released on its own, and Plasma Workspaces will also be released as its own product. The development cycles for the two parts have been decoupled, which will allow us to ship each when they are ready by defining devel cycles for each that works for each.
So KWin will be the Wayland compositor?
Ate plasmiods going to be out of process? Trivial to implement with Wayland. But I guess someone needs to tell the plasmoids where to go and that should be plasma.
Well the plan has been for years to make KWin the Wayland compositor and we have worked for that for years.
The plasmoid question I don’t really understand because nobody wants to do plasmoids out of process.
“Trivial to implement with Wayland.”
I’m trying to determine whether you don’t understand what Wayland does, or if you don’t understand what Plasmoids do, or if you don’t understand the meaning of the word trivial .. or some combination of those.
I look forward to seeing your patches.
Aaron, I’ve worked on a Wayland compositor for a year.
KDE 4 not having in-process plasmoids made sense given the technology stack. You would basically need to invent your own mini-Wayland to do to out-of-process plasmoids.
But with QML/QtWayland… placing an Item{} is just as difficult as placing a WaylandSurfaceItem{}. Which isn’t difficult at all. That’s what I mean by trivial. Obviously whichever solution is used will require a lot of supporting architecture. And for sure out-of-process isn’t free, you would need a forking process, IPC etc.
But is the plan to simply trust all Plasmoid creators again? JavaScript and render threads are not panaceas.
I think it’s the second option. Plasmoids are not windows.
and where’s then the difference to X11? Also with X11 it is trivial to render to an X pixmap and use that in form of a QPixmap inside a QGraphicsView or QML. I do not see where Wayland would change something for that usage…