I'm a little nervous about client-side window decorations. One of the nice things about window-system controlled decorations is that updates in function, policy and style can be done unilaterally. I'm worried that few years after the Wayland transition there will be a cluster of ugly legacy apps that will never be upgraded and don't work right- think xmms, not Google Chrome.
I'm apprehensive about the same things. Toolkit cooperation on Linux is bad enough now and I see no indication that any work is being done to even mitigate worsening as these changes give toolkits more control over user experience.
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.
> Google Chrome is much better than xmms because you can turn the client-side window decoration and custom colour schemes off.
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 don't get it- if you have "hide system title bar" off, there's just tabs, and then your window manager takes over and draws a 1px border. Do you want chromium to enable some mode where it /never/ has tabs, and /always/ spawns new windows? Or do you just want a different theme for the tab bar?
I'd like to get rid of all the remaining visible UI widgets in Chromium. That would be the address bar and the tab bar. Web page with 1 px border, no decorations or buttons, that's what I want.
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.
I'm the one who started working on client-side decorations for gtk+ originally, just as an experiment (but with encouragement from Kristian Høgsberg). After I quit Canonical I never heard that anyone else had picked up the branch, but every once in awhile I hear something about it when people start talking about Wayland.
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.
I think this is a people problem- it's rather separate from the low level technical details of how pixels get pushed to the screen. Linux is inconsistent precisely because its community has rejected the notion of strong centralised leadership, and inconsistency is simply the natural consequence of that philosophy.
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.
I see what you did there.
As soon as Ubuntu disallows non Ubuntu designed software from running, you might see some consistency. But what would the reaction in the linux community be to such a move?
They do not have to disallow anything to make Ubuntu more consistent: Apple does not disallow anything from being installed on OS X (even now that the Mac App Store exists) and yet OS X is a lot more consistent than any currently existing Linux distro.
I don't think you can compare Mac OSX to Ubuntu in this way. The mac developer culture is different from the linux developer culture, due to the strong presence of the original UI design and human interface guidelines. When something doesn't match the OSX experience, its easy to notice- because you have that strong baseline, and there's a strong motivation to write software that matches that baseline experience. software that runs in OSX's x11 is obviously not as good as "real" os x software. There is no base for linux, so any widget set or toolkit is just as good as another, and there's no strong reason to pick one or another language, or "platform" or library. You're invited to install this runtime or that scripting language to get arbitrary programs to run. And linux people like it that way. That's what freedom looks like.
Ubuntu has already been flamed to a crisp over Unity, so they might as well go all the way and remove all non-Unity apps. Fedora aka GNOME OS may beat them to it, though.
As hollerith said, Canonical just needs to create a strong default desktop experience such that everything the normal user wants fits into The Ubuntu Way. Weirdos like me will still be allowed to install Ubuntu, put Window Maker on it, and happily ignore The Ubuntu Way even as we take advantage of driver support and large and fairly up-to-date package repos.
Server-side window decorations make smooth (buffered with no tearing) resize behavior much more difficult than it has to be. I spent a decent chunk of time years ago trying to get better resize behavior in Qt/Kwin, and the necessary synchronization between the window manager and the app makes it a PITA.
You're an ass. Check out some of the latest research into functional reactive programming. They're pretty far along that track.
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
Well, I agree I was an ass there. When I read your comment I thought you were pushing something in the lines of "well, the problem is simple if you treat it with [insert hight-concept mechanism here]", which always gets a bit on my nerves. You know, like none has thought of the problem domain before? Anyway, I think I might have been mistaken.
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.
I also hope it doesn't break window manipulation when the app is locked up. The difference is that you generally can minimize a non-responsive app under X while on Windows it is trapped on screen.
I'm afraid I've got bad news for you. In current Wayland they're still trying to work out how the close button will work when the app is non-responsive.
Maybe it is me misunderstanding things, but Wayland and X11 are not technologies in contrast with each other.
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.
A key point is that X11 is no longer used for drawing; in recent years people are moving to client-side drawing (usually with Cairo). Thus the subset of X11 features that people use is similar to Wayland's features.
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.
I felt that the words like 'legacy' and 'dated' were a tad overused, and the article felt biased. A particular example was how X's protocols were described as "complex, asynchronous", contrasted with Wayland's "violently asynchronous" protocols !
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.
I went to a talk about Wayland at FOSDEM. What was most interesting was that everything they are trying to solve has already been solved by X. Furthermore, the only possible benefit of Wayland (rotating windows in non 90 degree amounts) is basically a bug, not a feature.
Then there's the lack of network support.
If this is pushed on Linux users, expect forking of distributions.
This goes to show that it's practically impossible to do it right. At one point there are the purists who complain about bloat. At the other point, there are the purists complaining about NIH when you try to remove the bloat.
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.
I use both OS X and Ubuntu. In comparison, Ubuntu is terribly slow, even on basic things such as dragging and resizing windows, let alone graphically-intense applications. This is both with ATI's proprietary drivers and the opensource radeon driver. Things are a bit better if I don't use a compositing window manager.
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.
I'm using Intel hardware on a large display, and of course Intel makes all the information available to driver writers and the X drivers are open source and very high quality. And there is no lag. I used to use Mac OS X before and there's no difference.
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.
The point of Wayland isn't doing new things that weren't poissible before, it's doing things in a better and more efficient way. Less lines of code, dropping support ancient unused stuff, etc. In other words, reducing technical debt.
> I went to a talk about Wayland at FOSDEM. What was most interesting was that everything they are trying to solve has already been solved by X.
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'm doing occasionally some cross-platform development using Windows API and X11 and what I hope mostly for is that Wayland will reduce the complexity when programming compared to what is needed for X. Even simply things get complicated on X11 due to the client&server communication. A simple call to check the cursor-position can freeze your application for several milliseconds when the server decides to ignore your client for a few frames (and yes, depending on the application that matters - for games it's really annoying). Or adding copy&paste support will send you through a hell of no-longer-working examples and you can find lots of custom implementation where no 2 people tried the same workaround to ensure they really wait long enough for the server to respond and filter the right messages. I think the X people are also working on improving the situation when client&server are on the same system, but unfortunately you never can really ignore that communication completely and it will probably be many years before older X11 systems out there can safely be ignored.
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.
One of my hats is 'system administrator'. I like X a lot more than VNC/RDP. I don't run linux on my desktop and don't really care about performance there.
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.
One the 2nd page near the end they discuss the feasibility of adding network-transparency to Wayland; according to the author Wayland is both hugely asynchronous (so network lag isn't a blocking issue) as well as completely event-driven, so receiving those events from a local process or a remote connection are the same thing to it.
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.
My impression is that Wayland planned to support X as a compatibility option. The difference is that X isn't the low level mediator of all input/graphics by default. As I understand.
I can imagine this being a real issue if it happens at the toolkit level; for example, GTK dropping X11 support. But until Wayland proves itself in the field as a real and superior competitor to X, it's absurd to suggest that even a significant proportion of distros would abandon X altogether. And as long as any distro of note (Linux or otherwise) still ships with X, it seems really unlikely that the major toolkits would indulge in such madness.
I wouldn't worry about it for another decade or so.
It's nice that there is still interesting development work being done in this field. This approach certainly seems like a step forward. Kernel Mode Setting is noticeably faster and has better power saving abilities than previous approaches but is cannot be fully taken advantage of by X.
The real problem, and confusion in this discussion is because X11 is a loaded concept and when people talk about Wayland they dont seem to understand what part of X11 wayland is supposed to replace.
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.
While many of the changes that Wayland is making seem like improvements, I would really miss server side window decoration if it were to go away. Perhaps a nice way forward would be to have, instead of X on Wayland, another lighter weight server between Wayland and the applications? I suppose this would be very analogous to current window managers.
I really have a feeling that X11 is beyond "good enough". Embedded systems wanting to use Linux have mostly had to do their own solution (Android, qtopia before that) because X11 was to heavy.
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.
