Forgot your password?

typodupeerror
KDE GUI Graphics Linux

KDE Plans To Support Wayland In 2012 413

Posted by timothy
from the good-first-name-for-a-baby-too dept.
An anonymous reader writes "During the 2011 Desktop Summit plans were brought up by a KDE developer to support KDE on the Wayland Display Server, which is dubbed the successor to X11. The KDE Wayland support is expected to come in three phases, with the first two phases expected to be completed next year during the KDE SC 4.8 and 4.9 development cycles. Farewell X?"
This discussion has been archived. No new comments can be posted.

KDE Plans To Support Wayland In 2012

Comments Filter:
  • Re:Stupid (Score:4, Interesting)

    by drinkypoo (153816) <martin.espinoza@gmail.com> on Sunday August 07, 2011 @09:55AM (#37013744) Homepage Journal

    Here's what X can do today that we will lose: Run applications on one virtual or physical machine and display on another. This is not the same as VNC or terminal services.

    Lately I have it not work for me pretty often. Especially if there's any OpenGL. I can have two machines with GLX on them and yet my application crashes when I try to display it on the remote one... practically ANYTHING using OpenGL asplodes. Any more, that's the only thing I want to display remotely, because any old janky computer has enough power to run apps locally. It's not like when I was having to run Netscape on Linux displayed back to my SLC because it didn't have the power to run it satisfactorily.

  • Re:Stupid (Score:5, Interesting)

    by Theovon (109752) on Sunday August 07, 2011 @10:13AM (#37013848)

    It's a myth that Wayland lacks network transparency. It currently doesn't DEFINE it, but it doesn't LACK it. That may sound like a semantic game, but it's the same as saying that X11 lacks policy, which is imposed by the window manager, a separate program. Wayland provides drawing surfaces to applications and then composites them onto the screen. There are many different ways in which the drawing surfaces can get moved from the client to the server for display. Locally, they're the same memory space. With remote applications, you can either move pixels, or you can have the rendering API send commands over the network.

  • Re:Not so stupid. (Score:4, Interesting)

    by TheRaven64 (641858) on Sunday August 07, 2011 @12:01PM (#37014536) Journal

    NeWS and Display PostScript were very similar, but there were some differences. NeWS encouraged you to write entire view objects in PostScript. This was a bitch to maintain, but it was great for remote display. With NeWS, you clicked on a button and it ran a PostScript program showing the button in the pressed state and sent a message to the remote machine saying the button had been pressed. With DPS and X11, you click on a button, and it sends a 'mouse click at coordinates x, y' message to the remote server. The remote machine then sends back drawing commands to produce a pressed button. Over a slow link, this means that NeWS buttons respond immediately, while X11 / DPS buttons respond after 100+ms. The closest thing we have now is the web. The canvas tag and JavaScript basically provide a modern version of NeWS.

    DPS was a bit different, and Apple ditched the programmability entirely when they moved to the PDF rendering model in Quartz. This means that the interface is simpler - you no longer need an interpreter in the display server - and the addition of all of the compositing stuff meant that you could do much better raster displays.

    Given that PDF is actually quite a dense format already, I'd be tempted to simply define the wire protocol for drawing as encapsulated PDF objects. This would let you store any sequence of drawing commands (e.g. a button shape, a text glyph composed of bezier curves, or an image) on the display server trivially and then redraw it at the current position with just a single command. It would be really easy to implement this with the canvas tag, so you could have a simple display server implemented in a web browser using WebSocket for remote display anywhere, and a proper native version for local and remote display.

  • Re:Stupid (Score:5, Interesting)

    by Mad Merlin (837387) on Sunday August 07, 2011 @02:53PM (#37015930) Homepage

    2. Help X11 by fixing what people perceive to be wrong with it. Maybe then you'll also see how bloated and painful it is to work with X11... (ultimately, that's the REAL reason we're seeing a rise of Wayland). You don't have to agree, you just have to realize that the people who disagree with you are about to overpower your choice. The mantra of "well, if they want it (the fancy animations), they should add it to X11 themselves or shut up" has failed you. Instead, someone has written an increasingly viable alternative which lacks features YOU want. Which leads me to ...

    This would be counterproductive. By far the most common complaint I see about X is "OMG IT'S SLOW BECAUSE IT ALWAYS RUNS OVER THE NETWORK!!!!!!!!". However, on a local display, X uses a domain socket for communication, basically the fastest method available. So, the perceived problem isn't actually a problem at all, "fixing" it would be a mistake.

    As far as I can tell, anyone who's backing Wayland has no actual concrete complaints about X, they just feel the need to rewrite everything from scratch (a common problem, unfortunately [wikipedia.org]). Furthermore, in all I've read about Wayland, it doesn't bring anything to the table except fewer features and newer (buggier) code.

    I don't know if you've noticed, but KDE and Gnome (and others) already have lots of fancy animations, and they didn't need to rewrite X to get it done.

If you learn one useless thing every day, in a single year you'll learn 365 useless things.

Working...