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.
