The Wayland Situation: Facts About X vs. Wayland (Phoronix)
The Wayland Situation: Facts About X vs. Wayland (Phoronix)
Posted Jun 10, 2013 9:16 UTC (Mon) by blackwood (guest, #44174)In reply to: The Wayland Situation: Facts About X vs. Wayland (Phoronix) by jzbiciak
Parent article: The Wayland Situation: Facts About X vs. Wayland (Phoronix)
What's holding things up is simply that other stuff is currently a higher priority (like plugging the holes in the input layer for input methods and fleshing out the window display mode a bit). But I guess it'll all be in place when desktops environments have working Wayland code, together with XWayland and all the other pieces we need to have for a well-working full-fledged Wayland desktop.
Posted Jun 18, 2013 11:20 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
I am told that in order to get such a rare and obscure use case to work I have to wait for toolkit-level remoting, which is as far as I can tell a complete mirage: nobody is working on it, nobody is planning to work on it, if people do work on it their work for distinct toolkits will be totally uncoordinated (natch), why aren't you happy with VNC-style bitmap shuffling nobody needs to scroll windows full of text anyway.
Posted Jun 19, 2013 0:14 UTC (Wed)
by daniels (subscriber, #16193)
[Link]
Again, this is completely false.
The Wayland Situation: Facts About X vs. Wayland (Phoronix)
The end result is pretty impressive.
Except if you want to scroll windows full of text, since that means repainting the entire screen rather than erasing a line from the top, shuffling the rest up, and painting a line at the bottom (or vice versa), since it has no understanding of the semantics of scrolling.
The Wayland Situation: Facts About X vs. Wayland (Phoronix)