Slashdot Mirror
Wayland Isn't Ready For the Fedora 24 Desktop (phoronix.com)
An anonymous reader writes: There was much hope that Fedora 24 would be the first major Linux distribution using Wayland by default in place of an X.Org Server, that didn't pan out with Fedora 24 Workstation developers deciding not to use Wayland by default but it will remain a log-in time option. Fedora Wayland has made a lot of progress but functionality like on-screen keyboard, accessibility, remote displays, USB display hot-plugging, and other functionality is incomplete for the Fedora 24 timeline. At least there are many other Fedora 24 features that made it for this next release due out in June. Wayland will turn eight years old this year.
For Fedora, which underpins RHEL and other Enterprisey OSes, that's a major absence, even if Wayland's own developers don't consider it important.
I really hope Wayland's developers stop treating it as a minority application unworthy of serious consideration (even though it's supposedly on their long term roadmap) and actively start work on it. They have a proof of concept. They have X to show them how security can work in practice. It's time the work was done.
You are not alone. This is not normal. None of this is normal.
Replacing X is a big project. Sometimes it takes a while to generate something good.
I'm not sure anyone has a good model for handling rewrites of massive projects. The experiences of KDE 4.0 and Gnome 3.0 come to mind. Eventually, they were better, but it takes some time with a massive upgrade like that.
The other issue is that User's often have a very good idea of what they don't like. However, bulimic criticism does not help to refine a software product. It just splits the ecosystem. Ultimately the user's need to use their computer, and the new software just isn't ready. So the developer's and user's go in different directions.
Closed source isn't the solution either: with Windows 8, Microsoft split it's ecosystem. Windows 10 hasn't fixed the split (yet).
From what I've understood, VNC yes since it's essentially diff'd screen dumps with "damage areas" that are redrawn. In fact there's been some attempts at making a RDP-style remote capability that is slightly smarter because it knows the composition but not the contents of the window, like if you move a window the protocol knows it can just move rather than resend the contents. What you won't get is native X acceleration, meaning you can't actually send draw commands. Think like HTML, draw this box here with that text in this color.
That is also why Wayland at least in the reference implementation doesn't have server side decorations, it doesn't want to understand fonts, antialiasing, buttons, animation, themes and all that. It is only a pixel-pusher, it composites images other software has made. By itself it won't draw a window border, a minimize/maximize/close button, nothing. It made the project much easier without dependency on any graphics toolkit, but I think it might have been a mistake to present it like this is the norm and clients should/might have to write their own decorations.
I don't think applications should be forced to write their own decorations, it should be the norm that they can request decorations from the window system and that they'll take what they can get. The reference implementation should have been a wayland plug-in and might have been state of the art of the 1980s, a few fixed bitmaps and just "we expect actual environments like KDE, Gnome, even XFCE to come up with something more advanced this is basically a minimal placeholder". If you want to draw your own decorations that's something else.
Live today, because you never know what tomorrow brings
+1
We run over 150 [Linux based] thin clients using X11R7, and before than, on X11R6. And being thin, that means remoting the ENTIRE DESKTOP SESSION- window manager, clients, everything. And those client apps come from various places on various servers, sometimes even the local machine.
Now, this is a *BUSINESS* environment.... we are not trying to push video games, music, or movies through X11. That won't work well. But Firefox, LibreOffice, Clawsmail, GIMP, Pluma, Inkscape, Pidgin, PDF viewers/writers, etc, and all our AP/GL/AR/Payroll/etc work just dandy.
> From the XFree86 web page:
>> XFree86 Release 4.8.0 is out NOW
>> 4.8.0 release was released on 15 December 2008. Our next full release will
>> be 4.9.0, and is expected to be released in the summer/winter of 2009
[...deletia...]
> How's that working out for you?
In case you missed it, there was an internal revolt inside the XFree86 group, and XFree86 code was forked as Xorg, which is the current implementation. The last person to leave the XFree86 project forgot to turn off the lights.
XFree86 is passed on! This project is no more! It has ceased to be! It's expired and gone to meet its maker! It's a stiff! Bereft of life, it rests in peace! If you hadn't nailed it to the perch it'd be pushing up the daisies! Its metabolic processes are now history! It's off the twig! It's kicked the bucket, It's shuffled off its mortal coil, run down the curtain and joined the bleedin' choir invisibile!! THIS IS AN EX-PROJECT!!
See the current Xorg location http://www.x.org/wiki/ It actually has stuff from late last month, rather than late last decade.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
That is why we should have been putting effort into something 100% backwards compatible with X11... X12. All kinds of things COULD have been rolled in- compression, local cursor, broadcast, etc.