Plugins, Plugins, Plugins: Supporting Them On Wayland

[phoronix]

Phoronix: Plugins, Plugins, Plugins: Supporting Them On Wayland

Long time Kwin maintainer Martin Graesslin penned another blog post today, this time discussing his work getting KGlobalAccel, KIdleTime, and KWindowSystem to play nicely under a Wayland session, rather than an X11 based session...

http://www.phoronix.com/scan.php?page=news_item&px=KDE-Plugins-Wayland

[Awesomeness]

I really hope Plasma 5.4 will have somewhat usable Wayland support out of the box. (I'm not hoping for a totally production-quality first release ? that would be unrealistic.)

[brotiger]

So here's what I've learned about this whole KDE/Wayland fiasco:

• Instead of solving most things in the display manager, so everybody is on the same starting page and gets the same features, Wayland solves just about everything (especially multi-monitor, decorations etc.) on the client side, multiplying the amount of work for everybody and creating a huge feature disparity between different desktop environments and UI toolkits.
• You can basically throw your existing codebase away when switching to Wayland, not only not gaining a single new or "advanced" feature in the process, but having to fight hard to get your old features back.
• It takes four years to not get it stable, while other people build a complete display manager system AND a completely new desktop that already ships on tens of thousands of phones in just two years.
• Still no support for anything that looks like a network transport.
• Half of the patches in every new KDE release, and 100% of the patches for Wayland support, come from Martin Gr?sslin. So without him the project would pretty much not have a future?

[zanny]

So here's what I've learned about this whole KDE/Wayland fiasco:
Instead of solving most things in the display manager, so everybody is on the same starting page and gets the same features, Wayland solves just about everything (especially multi-monitor, decorations etc.) on the client side, multiplying the amount of work for everybody and creating a huge feature disparity between different desktop environments and UI toolkits.

Wayland provides a reference compositor called Weston. It has always been Gnomes and KDE's onus not to use it. Almost all the blinged out Wayland demos are done on Weston, where they also have a lot of Wayland specific functionality like arbitrarily rotated windows or non-rectangular frames. Wayland the library and protocol are just a window management API, not anything like X where you run a server binary that acts as the window manager. Your compositor is the window manager under Wayland.

You can basically throw your existing codebase away when switching to Wayland, not only not gaining a single new or "advanced" feature in the process, but having to fight hard to get your old features back.

Kwin explicitly was not depreciated because a tremendous amount of code sharing continues to occur between X and Wayland compositors like Mutter and itself. Martin made a post about it recently, and only about a quarter of the project tree is window system dependent.

It takes four years to not get it stable, while other people build a complete display manager system AND a completely new desktop that already ships on tens of thousands of phones in just two years.

Real work on Wayland only really started Post KDE 5.0 release. Before that Wayland was still seeing feature development and developers were more focused on all the KDE 5 changes. So real work has only been going on for about a year, and Martin recently mentioned that almost all Kwin work before 2014 on Wayland was thrown out to made it a proper full Wayland compositor without having to run as a client of another one (ie, Xserver or Weston).

The real work from Qt's perspective was done two years ago - the Lighthouse window manager plugin infrastructure happened in 5.0, and Qt applications built on Qt 5 can, and do, run on Wayland servers just fine. All this is is Kwin being turned into a Wayland compositor. Plasma Shell also needs some work, because like Martin mentions it and several other Qt projects still directly invoke Xorg and need all that code either refactored into API generic stuff with EGL or something or have Wayland versions implemented.

Still no support for anything that looks like a network transport.

Wayland will never have something as out of scope of the projects description (window management) as having a way to send the desktop over a network interface. You can easily integrate RDP into your shell or GUI remote desktop software, or even into your Wayland compositor. Nothing stops Kwin from being an RDP server, besides the fact KRDP already exists to provide that functionality.

Half of the patches in every new KDE release, and 100% of the patches for Wayland support, come from Martin Gr?sslin. So without him the project would pretty much not have a future?

Martin is the project lead, and is paid full time to work on, Kwin. So yeah, most of the Wayland porting work from the side of "implement a Wayland compositor for KDE" is his job. Without him nobody would be full time developing any KDE wayland compositor, but without Martin the ecosystem would either load balance the work or decide Weston is good enough and use that. Not sure how it would have gone.

But he is also project lead, so these blog posts are talking about what he is doing, and what macroscopically Kwin the project has accomplished, but there are still contributors of varying degrees to the project and to the frameworks hes using in Kwin. Its not a one man job.

[M1kkko]

It takes four years to not get it stable, while other people build a complete display manager system AND a completely new desktop that already ships on tens of thousands of phones in just two years.

Are you aware that Jolla, the phone that launched in 2013, is shipping with Wayland?

[panda84]

Are you aware that Jolla, the phone that launched in 2013, is shipping with Wayland?

Hater's gonna hate.
If he was in good faith he would have compared similar things:

• Gnome Shell on Wayland (initial support in Fedora 21)
• Plasma on Wayland (initial support in Plasma 5.4)
• Unity 8 on Mir (initial support in Ubuntu 15.04)

[renox]

Wayland provides a reference compositor called Weston. It has always been Gnomes and KDE's onus not to use it.

1) Weston has been called a 'prototype' by Wayland developers to show how things should be done, but several times (when rejecting features) they stressed that Weston isn't meant to be used directly by DE.

2) all what you said doesn't contradict what brotiger said, his points are still valid, especially this one "Wayland solves just about everything (especially multi-monitor, decorations etc.) on the client side, multiplying the amount of work for everybody and creating a huge feature disparity between different desktop environments and UI toolkits."

One glaring example: even though you CAN add a network protocol on top of Wayland, it isn't there by default which means that some existing GUI based on Wayland DON'T have it, which is a regression for users which used X11 based technology before.

[Temar]

Wayland provides a reference compositor called Weston. It has always been Gnomes and KDE's onus not to use it.

That's what's worrying me. Are KDE and GNOME working together to design a common, compatible compositor or is (as always) everyone inventing his own version of the compositor. How well will KDE applications run in a GNOME environment and vice versa?

As KDE and GNOME can not even agree on a a common file selection dialog, I can see a disaster ahead.

It was a mistake from the Wayland crew not to provide a reference compositor which is actually usable for both projects, without having to reimplement their own version.

[89c51]

One glaring example: even though you CAN add a network protocol on top of Wayland, it isn't there by default which means that some existing GUI based on Wayland DON'T have it, which is a regression for users which used X11 based technology before.

There is one prototype implementation of a remote protocol that noone bothered bringing up to date and making it production ready.

[Auzy]

You can basically throw your existing codebase away when switching to Wayland, not only not gaining a single new or "advanced" feature in the process, but having to fight hard to get your old features back.

Said no X11 developer ever. X11 is the perfect attack vector and vulnerabilities are constantly found. Even the official Xorg developers don't hesitate to list its inefficiencies and design problems..

Still no support for anything that looks like a network transport.

Why do you need this?
When people say this without being upfront for the technical reasons why they need it, its a seal of assurance that they don't actually need it, but wanted to bolster their argument. If they did have a valid reason, they would add it to their argument immediately, to give it credibility. Network transparency does have its uses, but, its actually quite rare. Even in X11, very few people used it, and many who did, were solving problems they had in the wrong way.