Original Article by Martin Gräßlin, published on his Blog
Every time there is an article about Wayland you can see that there a lots of uneducated comments about the “fact” that Wayland does not support network trancparency and because of that it is completely wrong to go for network trancparency. These discussions contain a lot of myths and even FUD and I consider it important to share my thoughts about these concerns as I am belonging to those who actively work to bring the benefits of Wayland to the KDE Plasma Workspaces.
Wayland Could Use Network Transparency
Nothing in the Wayland protocol forbidds network transparency. It is not yet implemented, but it is possible to implement it. Wayland uses a Unix Socket for communication but I think it would be rather trivial to either add network transport to the Wayland protocol or to just forward the buffer in the compositor. Stating that Wayland does not support Network Transparency in general is just wrong. It’s not yet implemented but many things are not yet implemented. Obviously it’s true that the Wayland protocol does not support the X11 Network Transparency as it’s not X11 (and that is a good thing). Obviously even a direct X11 successor (let’s name it X12) would also not support the X11 Network Transparency.
X11 Network Transparency is not Suited for Modern Applications
The idea behind the network transparency is to send drawing commands over the wire (useful idee for the requirements of 30 years ago). Nowadays modern applications do not use X11 any more for rendering. They use technologies like Cairo, Clutter, QPainter (Raster) or OpenGL directly. Without using X11 for rendering you end in streaming pixels over the wire. And there are clearly better technologies to do that than X11. Face it: network transparency is going to break very soon even without Wayland. I want to see the Qt 5 used over the wire.
Modern Applications require DBus
Yes DBus is not network transparent and yes most modern application use it, for things like StatusNotifier (this one has fallback to Xembed) or moving the menus somewhere else. Now without network transparency these things are just shown on the wrong system or not at all. Damn stupid devs not thinking about network transparency… So face it: no modern app can be used without DBus which breaks implicitly also the X11 Network Transparency.
Wayland targets Mobile Devices
Desktop will continue to Support X11
We will only switch to Wayland as our primary windowing system if we can continue to support legacy X11 applications, because we don’t want to break the desktop. This means you can still run your legacy X11 windows over network even under Wayland and also X11 applications on the Wayland system can still be forwarded to a remote system. So I hear you already complaining about the Wayland windows not being able to be forwarded. Well if the toolkit (like Qt) supports multiple backends there is no reason why you should not use the X11 backend to forward the window. Apart from that: remember, it would not be working at the time when we switch to Wayland even under X11 (see above).
Network Transparency Does Not Belong Into The Windowing System
Adding Network Transparency in the Windowing System is the wrong layer. The windowing system only receives the pixels and that can never be performant. Network Transparency needs to be added to the layer which does the rendering. That used to work with X11 as X11 also did the rendering, but this is not true any more. We need support for Network Transparency in the toolkit. Just imagine the possibilites: remote applications picking up your local font settings, color themes, icon themes… That’s what needs to be done!
But Distros will remove X11 support in $X Years
> As long as there is a demand for legacy support distros will still support it.
While I generally take a cautiously optimistic attitude toward wayland, and in fact agree with pretty much everything else you said…
This bit sounds WAY too much like Aaron Segio’s very public and (in)famous pledge about KDE 3 support continuing to be there “as long as there were users”. We all know how /that/ one turned out, with distros dropping support left and right about the time of the still VERY broken kde 4.2 (despite public kde claims to the contrary, belied by the bugtracker for the very project making the claims!), because kde itself was dropping support for it, and nokia/trolltech had already dropped support for the qt3 on which it was based.
When someone as prominent in the kde organization as Aaron Segio said that, many people, including me, believed him, rather unfortunately as it turned out, since it all turned out to be lies. If kde /had/ honored that pledge and continued support for their actually /working/ version at least until such time as kde4 was similarly working (not just by claims, but backed up by the bugtracker’s successful resolution of all those “not yet in kde4” bugs), then the kde4 debacle wouldn’t have been half as bad as it was because people who actually needed a /working/ desktop could have waited until kde4 was actually usable. (IMO, 4.2 was still alpha, many kde3 features not yet even there as confirmed by the bugtracker, 4.3 beta, most features there but raw, 4.4 rc, most features reasonably working but still some critical corner-case-bugs to fix and polish needed, 4.5 finally first stable release quality, good for mainstream “early adopter” adoption, 4.6 slipped a bit, but 4.7 looks good so far, at least here, for the “cautious stable” folks, at least those who don’t use or are willing to dump anything akonadi and thus kdepim related, which I “waited and saw”, and decided was an aircraft carrier where a rowboat with a trolling motor far better fit my needs..)
I always knew kde would pull out of the problem, and certainly can’t blame what is after all very much a volunteer project for taking longer than one might have liked to get things right as I expected they would, thus my sticking with it, but the oh, the unnecessary pain of the transfer, made the more unnecessarily painful by broken pledges and people that insisted a broken POS was “ready”, despite admitting it wasn’t on a case-by-case basis in the bugtracker, the better to “conveniently” drop support for the /actually/ working version.
Despite all that I’m a bit of an optimist and thus hope and expect that it WILL be different, this time, “really”, but I’m also a realist enough not to actually believe it until I see it, /this/ time. As they say, fool me once, shame on you, fool me twice, shame on me, and unfortunately, this type of pledge has way too many parallels to that previous one to be at ALL comforting. Oh, well. Time will tell, I guess.
But the caution toward breaking the desktop is noted, AND appreciated. =:^) Perhaps history won’t repeat itself this time after all. Time will /indeed/ tell.