Wayland - Beyond X(h-online.com) |
Wayland - Beyond X(h-online.com) |
Google Chrome is just as bad if not worse than xmms because it's so loved; I'm a firm believer that user interface improvements should be shared between programs rather than implemented as one-off exceptions to the system setup. If it's a real improvement I'm bound to want it elsewhere, and if not, the loss of consistency isn't worth the small gain for that particular application.
Still not as attractive as Firefox, to my mind, but that's opinions for you.
Anyway, I was never really worried about the things that you're worried about. xmms proves that anyone who wants to write a shitty, completely custom UI with shitty window decorations is perfectly capable of doing it already. In fact, the gtk+ client-side decorations branch didn't make it easier for someone to do that the way everyone seemed to think it did.
http://blog.martin-graesslin.com/blog/2010/05/why-you-should...
http://www.hadess.net/2010/05/client-side-windows-and-miscon...
It's different with something like android, that has something like a canonical organisation that can set interface standards. Vanilla linux has no entity with that much credibility.
With a well-specified server model (say using temporal logic), there should be no problem attaining pixel- and frame-perfect rendering.
Wayland is a glorified and up-to-date framebuffer and input system, X11 is a library that draws shapes and is responsible for delivering input from the user to the correct application.
I think the current situation is confusing because current X11 implementations not only do what X11 is meant to do, but they also need a way to push pixels to the framebuffer and listen to keystrokes. Basically X servers needed their own way to talk to the graphic card and they implemented it (decades ago). That part is almost completely independent from the protocol that draws shapes and routes input to applications. What Wayland is replacing is _that_ part, the part that deals with the framebuffer (that in the modern times is no longer a simple strip of memory region with RGB pixel data).
In the end we will have Wayland as the only owner of the graphic device and many clients, one of which will be the X server. When they say "client-side decoration" they are referring to the status quo: the Wayland client called X11 will draw the decorations (asking the WM to do that); nothing different from what we have now.
Once Wayland will be stable there will be other direct clients that will want to bypass X11: games probably, but also other multi-platform toolkit like Qt. And X12, eventually ;)
To me Wayland looks as the perfect example of how to move forward: make older unsustainable technologies coexist with newer technologies.
When people talk about client-side (really the toolkit) decoration, that's in the native Wayland case, so it is different from the way it's done today.
http://www.h-online.com/open/features/Wayland-Beyond-X-14320...
It's always thrilling to have a blank slate, and you have a euphoric feeling that this time, we're going to get it right. But there are the essential complexities of any problem, and I would say that for the end user, X has delivered in spades. It will be interesting to hear developers reactions to a battle-tested Wayland code base 5 years from now.
Then there's the lack of network support.
If this is pushed on Linux users, expect forking of distributions.
I'm not looking forward to the day when X is gone. Being able to fire up system-config-* on a remote system is awesome.
I don't think we'll all have what we want soon, it sounds like mid-2013 or end of 2013 before all the dust is settled and we know what our Wayland-future has in store for us.
Until then, there looks to be just too much low-level work to get done to try and guess where it will all fallout.
There is an experimental port to Arch if anyone want to give it a spin (https://wiki.archlinux.org/index.php/Wayland).
X11 meanings:
- X11 protocol: Allows remote applications.
- X11 server: Controlling applications and redirect input and such.
- X11 drivers: Controlling hadware.
As i understand it, Wayland is supposed to replace X11 drivers and parts of X11 server. Apparently you can still use the X11 protocol on top of Wayland if you want.
Theres a good FAQ about it: http://wayland.freedesktop.org/faq.html
I really like Wayland and would like to see it succeed though.
Changing Screen resolutions on the fly (think: "projector being connected") still is a lottery, mutli-monitor support usually requires a lot of manual intervention, bad drivers still can cause X11 to crash and take everything else with it, there are still graphical glitches when the system is busy.
For years - heck - decades, Linux distributions have tried to make this work, but I think that we are now at a point where everybody agrees that it can't be fixed within the framework of X11.
So the question is: "is clunky behavior good enough? Is being forced to use completely different technology on mobile devices (= less code sharing) good enough?"
While the answer was yes 5 years ago, it's not longer true and that's why I'd give Wayland more chances now.
You can't have it both in this case it seems.
As a user I know one thing: X11 is huge and while it has all the nice features, it's also still a slow and laggy beast. This might be caused by bad drivers, or it might be caused by a bad architecture (or bad drivers caused by bad architecture making it impossibly hard to write good drivers).
As such, I'm curious to see whether a restart based on technology newer than the 80ies might solve the two big issues I'm having with Unix GUI at this point.
If it does, I'm happy.
If it doesn't, I'll be on the lookout for a better solution.
But I know one thing: If a long-year X11 developer (Kristian Høgsberg is working on the xorg x server) tells us that our issues are practically impossible to fix without a rewrite using a different architecture, then I believe them. Why?
Because for them it would likely be much less work to fix the existing thing (especially if it is nearly 30 years old and as such should be very mature and bug-free), so if they prefer a rewrite, there must be some truth to that.
Personally, I don't care about either bloat (unless said bloat leads to other issues than me having to buy a bit more RAM and diskspace) or NIH, but I still to this day haven't found a Linux distribution that has a GUI which works as-well as OSX or Windows (window drawing issues, multi monitor support - heck - just changing resolutions at times), so I'm certainly open to see other paths explored.
(Edit: I use XFCE, not GNOME)
This is because Wayland is meant to be a subset of the functionality of X. It's not meant to do new things, it's meant to strip off 3 decades worth of cruft that is of little value today.
Note that Wayland is not ran by a bunch of random people who decided that X sucks and that they can do better -- a vast majority of the commits are by veteran X developers.
I realize many people care a lot about the network part of X11. I suppose especially if you are working as Sysop it might be a big deal. I've not used it for over a decade, so obviously not something I care about so much. But on the programming side that client&server split makes life a lot harder and is not a solved problem.
I wouldn't worry about it for another decade or so.
I am not sure who is to blame, X or the drivers. But most users won't care. They'll see that GNU/Linux has a bad desktop experience, and revert to whatever they were using.
So this sample of two users seems to indicate that your problem is with drivers. Wayland will make no difference to your experience of Ubuntu.
How? I didn't know this was possible and tried it (after some googling). Basically I have two choices: bad and worse. The default has the tabs on top. If I enable "hide system title bar", it adds a frame with close, minimize, maximize buttons.
I use a window manager with no decorations, just 1px border around active window. I'd like to get rid of the Chromium custom ugly tab bar.
I still want my tabs inside the browser (my wm doesn't have tabs for every window like ion3 or kde kwin). However, I don't want the tab bar to be visible unless I'm in the process of changing tabs with ctrl-tab. Same goes for the address bar, I'd like to see it only when I'm typing to it.
I used a browser called Luakit for a while. It's a WebKit-based browser that has a user interface that's built with Lua and has a Vim-like default setup. It worked quite well but I changed back to a conventional browser when I couldn't get a proxy set up with good ad blocking, etc (luakit has no proxy or ad blocking, it relies on you installing polipo+privoxy or another http proxy setup).
So these days I use Chromium but I would love to get that minimal UI look and feel from luakit.
Edit: if you want a hint at an actual solution, one need only send logical local timestamps along with each request, and introduce a timestamp handshake. The server very simply then need not swap in the backing store until it and the client have acknowledged that the logical timestamp should increment. Your convo then looks like this:
U - user / S - server / C - client
U->S: resize to 800x600
S->C: resize to 800x600, timestamp 12345
C->S: GL commands, timestamp 12345
C->S: more GL commands, timestamp 12345
C->S: more GL commands, timestamp 12345
C->S: OK, I'm done with timestamp 12345
S: render window decorations on C's backing buffer
S: push C's backing buffer from 12345 to the front
S->C: OK, it's now timestamp 12346
Also, I totally see how this is difficult (or maybe even impossible) in X, where the window manager is a separate client and there's no notion of inter-client synchronization. I haven't looked into Wayland enough to see what problems it presents (last time I checked it was in a state of major flux) but here's hoping its design entails a much simpler display model.