FOSDEM: The Wayland display server [LWN.net]

FOSDEM: The Wayland display server

Posted Feb 22, 2012 7:38 UTC (Wed) by mina86 (guest, #68442)
In reply to: FOSDEM: The Wayland display server by khim
Parent article: FOSDEM: The Wayland display server

> This is “an obvious conclusion” which feels like it does not even need any justification. Sadly practice does not support it. MacOS Classic, Windows and other systems used this approach - and all of them had much better consistency then what we have in X world.

I claim that's incorrect statement. Window decorations were never issue for me on Linux. They are always consistent. Exactly because there is a single process handling them.

Besides consistency, because window manager draws decorations, I can easily configure different decorations (or lack of decorations) for different windows.

to post comments

FOSDEM: The Wayland display server

Posted Feb 22, 2012 9:59 UTC (Wed) by khim (subscriber, #9252) [Link] (5 responses)

Window decorations were never issue for me on Linux.

Nice strawman. I'm not talking about window decorations (but see below). I'm talking about interface hall of shame. Where Unix/Linux is primary exhibit: all programs use different approaches (sometimes OK goes to the left, sometimes to the right, different programs use different shapes and forms for basic elements like checkboxes, etc). Window decorations are lipstick on the pig. All OSes have programs which look inconsistently - it's always possible to do, but if anything belong to hall of shame it's Linux with it's "progressive" architecture, not other OSes which use "obviously brain-dead" approach.

Now back to the question of window decorations. Note that while in MacOS or Windows the programs which explicitly decided to use "something different" look out of place (things like ICQ or MS Office) but in Linux it happens with programs which don't try to do that, too (think Google's Chrome).

Besides consistency, because window manager draws decorations, I can easily configure different decorations (or lack of decorations) for different windows.

Right. 1001th time where Linux punishes application developers "to empower users". In the end users don't feel all that empowered: they find out that they don't have access to their favorite applications and choose to use the other platform.

BTW you can do that in MacOS or Windows, too: since most application use standard functions to draw the decorations you can intercept appropriate functions and draw different decorations. It'll not work with all applications (some will not use standard functions or they may use some of them but not others), but again: in this case the person who changes the status quo feels the pain, not Joe Average who just wants to use his computer, not twiddle bazillion options day and night.

FOSDEM: The Wayland display server

Posted Feb 22, 2012 10:32 UTC (Wed) by halla (subscriber, #14185) [Link] (1 responses)

The big problem on Windows and OSX is that if the application is unresponsive for whatever reason, and that happens and will happen, you cannot move the window anymore or use the buttons to close the window since all that is handled by the application.

I had my IDE being unmovable on Windows only this morning while it was reparsing a big project. I've had Safari unmovable, unclosable on OSX.

FOSDEM: The Wayland display server

Posted Feb 22, 2012 11:04 UTC (Wed) by khim (subscriber, #9252) [Link]

Actually Windows7 after few second of unresponsiveness will draw it's own controls and these can be used to kill the program.

But these are rare cases. More obnoxious is the fact that you can not move window when popup is opened - and you often want to do that exactly to fill the information in popup (not that this happens with Chrome on Linux, too).

It's all about tradeoffs. MacOS/Windows (and apparently their users) value uniformity significantly higher then raw power of the interface while traditionally Unix/Linux valued the ability to create what you want from small independent components. The problem here lies in the fact that this increases not just power but the complexity for end user - and this leaves 99% of them in the dust. That, in turn, creates vicious cycle: with so few users ISVs and hardware companies abandon the platform and eventually these "empowered users" start to leave it because they grow tired of constant fight with the faults in the platform.

I think the Unix/Linux GUI finally follows in footsteps of other, more mature industries: early cars had a lot interesting and different "UI concepts", but today they all are abandoned. I'm pretty sure people bemoaned this development back then similarly to how today they bemoaned poorer and poorer support for FFM.

FOSDEM: The Wayland display server

Posted Feb 22, 2012 16:35 UTC (Wed) by mina86 (guest, #68442) [Link] (2 responses)

> Nice strawman. I'm not talking about window decorations (but see below). I'm talking about interface hall of shame.

OP was referring to window decorations and that's why I was referring to them as well.

Moreover, Wayland does not change the way user interface is drawn so there will be no improvement (in terms of UX) in this regard. The thing that changes are who draws window decorations.

> Now back to the question of window decorations. Note that while in MacOS or Windows the programs which explicitly decided to use "something different" look out of place (things like ICQ or MS Office) but in Linux it happens with programs which don't try to do that, too (think Google's Chrome).

Google Chrome tries to do something different since it does not want to have regular window title to save space.

> Right. 1001th time where Linux punishes application developers "to empower users". In the end users don't feel all that empowered: they find out that they don't have access to their favorite applications and choose to use the other platform.

I have no idea what you're talking about.

> BTW you can do that in MacOS or Windows, too: since most application use standard functions to draw the decorations you can intercept appropriate functions and draw different decorations.

Which is not true for Linux which has half a dozen different toolkits. I regularly use 3 that I can identify. Intercepting calls to all of possible toolkits is hardly a possibility.

This is why doing window decorations on client side will lead to all windows having different decorations -- if we had a single toolkit, that could be avoided but that's often not the case on typical Linux system. If you say it's bad now, it'd be worse if even window decorations were drawn by the client.

> in this case the person who changes the status quo feels the pain, not Joe Average who just wants to use his computer, not twiddle bazillion options day and night.

Joe Average can use Ubuntu and stick to its default settings and default applications. I don't see your point here.

FOSDEM: The Wayland display server

Posted Feb 22, 2012 17:04 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

Joe Average can use Ubuntu and stick to its default settings and default applications. I don't see your point here.

It is difficult to get a man to understand something, when his salary depends upon his not understanding it! The whole point of general-purpose OS is to support bazillion applications. If you want closed appliance then there are lots of much simpler alternatives (from PS3 and XBox360 to VCR and Internet-enabled TV) thus support from ISVs is vital. Default applications just don't cut it! There are more Android applications then X11 Linux application - by far! And Android is few times younger then X11…

Why? Because Desktop Linux never considered needs of ISVs seriously. The best offers they've ever got are unstable ABI (not compatible between different versions of Desktop) and/or LSB (which is stillborn because it tries to create "ISV layer" as something separate from the core OS).

Which is not true for Linux which has half a dozen different toolkits.

Which is true for MacOS and Windows, too. Somehow it does not change the fact they all use common code to draw windows decorations.

This is why doing window decorations on client side will lead to all windows having different decorations -- if we had a single toolkit, that could be avoided but that's often not the case on typical Linux system.

Well, perhaps it's time to fix that problem instead? I'm not talking about killing high-level toolkits, but if we want to reach some kind of consistency then moving common functionality to common place makes sense. This is doubly true for the new functionality like the ability to draw windows decorations.

FOSDEM: The Wayland display server

Posted Feb 22, 2012 17:37 UTC (Wed) by mina86 (guest, #68442) [Link]

> It is difficult to get a man to understand something, when his salary depends upon his not understanding it!

Oh, a personal attack! How sweet.

> The whole point of general-purpose OS is to support bazillion applications.

I'm not denying that. But the point is that Wayland will in no way improve situation with inconsistent UIs. If anything, it will make it worse because of window decorations. In the whole “interface hall of shame”, window decorations are the only thing that are usually consistent on Linux.

> There are more Android applications then X11 Linux application - by far! And Android is few times younger then X11…

Android applications don't have such a consistent UI either.

> Which is true for MacOS and Windows, too. Somehow it does not change the fact they all use common code to draw windows decorations.

Agreed. But from the talk, my impression is that it's not what Wayland is about to do. My impression is that each toolkit will handle everything on their own and Wayland will merely paste bitmaps on the screen.

> Well, perhaps it's time to fix that problem instead? I'm not talking about killing high-level toolkits, but if we want to reach some kind of consistency then moving common functionality to common place makes sense.

Agreed. My point is that Wayland does not do that and does not fix any real problems.

At the same time, it takes away what some love about X -- network transparency (and before someone tells me that do transferring bitmaps is good enough, please try VNCing over an SSH tunnel and VPN going across Asia; my experience is that X forwarding works much better (even if not perfect)).

High level toolkits are fine, but in my view, a low level toolkit should be defined (think: rendering API) which those would use. If done properly, this low level toolkit could be defined in such a way that it would work perfectly over network but when run on the same host, would talk directly to graphics driver (or something).

After watching the talk, I had this strange impression that speaker started by saying how toolkits no longer use rendering API and this is the reason not to have rendering API. My take on this is that I may agree with the presumption but my conclusion is that the toolkits need to be changed.

> This is doubly true for the new functionality like the ability to draw windows decorations.

I don't really agree on this though. For me, clients should not care about what's around their windows -- its content that they should care about. It's a bit like windows not caring where they are placed on the screen. This gives consistency, an easy way to control window decorations as well as window decorations not hanging when application hangs.