Slashdot Mirror
Gnome 3.12 Delayed To Sync With Wayland Release
sfcrazy writes "Gnome developers are planning to delay the release of Gnome 3.12 by approximately a week. It's a deliberate delay to sync the release with the availability of Wayland 1.5. Matthias Clasen (Fedora and Gnome developer) explains that 'the GNOME release team is pondering moving the date for 3.12.0 out by approximately a week, to align the schedule with the Wayland release plans (a 1.4.91 release including all the xdg-shell API we need is planned for April 1). The latter 3.11.x milestones would be shifted as well, to avoid lengthening the freeze period unnecessarily.'"
I've read through the Wayland site and another half dozen pages that are obviously over my head and I just don't understand what Wayland is or what it's advantages are. I think it's suppose to be replacing X11, but I don't really understand X11 either, other than it's a method of getting things onto the screen. So I'm throwing my ignorance out there hoping I won't be flamed out of existence and someone can explain or point me to a laymen description of Wayland, and/or X11 and how one is better than the other. It seems like it should be a big deal since I've read there's been a lot of dissatisfaction with X11 for quite sometime and yet no one's ever done anything about it. That is until now, if Wayland is in fact a replacement
I'm sorry I realize this has been discussed several times and I'm sorry I'm just not getting it.
Say, forever? MATE with Xorg is much more suitable than either Gnome or Wayland.
Ummm, even MATE is planning on switching to Wayland, so evidently the developers of MATE would disagree with you.
X is an application that runs on a computer with a graphics card. A graphical application can then use the X libraries to send drawing commands over the network to an X server, eg "draw a line", "draw a box", "display this bitmap", "display this string in font zzz". Note that the concept of "client" and "server" are somewhat reversed from the normal meaning - the X "server" runs on your desktop, the client can run somewhere in a datacenter. Think about apps processing major datasets and then generating some output...makes sense then for the "client" to be on the larger computer.
The X "server" also controls keyboard/mouse/etc, sending events to the relevant client apps.
The problem with X is that the whole design no longer matches what client apps want to do - eg interact with 3d-capable GPUs, use exactly the fonts they want (rather than asking the X server to use the font with a specific name, and hoping the server has that font available). And the network layer inbetween adds latency. And the set of commands that X supports is now so large that the server is huge - making it buggy, full of security holes, and difficult to maintain.
Wayland is basically the lowest-level parts of X (handling the graphics card), plus a very simple API for clients - it accepts bitmaps only, no "draw a line" stuff. And no network support - clients are local only. Client apps can then code directly against the Wayland APIs (ie pass it bitmaps, often generated by interacting directly with a GPU to render 3d graphics into a buffer). Fast, simple. Or clients can code against the original X API, in which case the drawing commands are sent across the network as they always were, and then are handled by a slimmed-down X-server which executes the commands and passes the resulting buffer to the local wayland server.
In practice of course, most apps will code to the GTK or QT apis, and it is GTK/QT which is responsible for interacting with Wayland or X.
There is also code in development to create a "wayland network protocol" where clients can generate images (on whatever computer they are running on - which might have a GPU), and then send the (compressed) image over the network to another wayland server where the user actually sits and sees the graphics. This is a kind of "RDP remote desktop" mode - and according to many people will actually out-perform the old X way of doing things, as well as being vastly simpler to implement/maintain.