Recent Features
| |||||||||||||
FOSDEM: The Wayland display serverFOSDEM: The Wayland display serverPosted Feb 22, 2012 16:35 UTC (Wed) by mina86 (subscriber, #68442)In reply to: FOSDEM: The Wayland display server by khim Parent article: FOSDEM: The Wayland display server
> 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.
(Log in to post comments)
FOSDEM: The Wayland display server Posted Feb 22, 2012 17:04 UTC (Wed) by khim (subscriber, #9252) [Link] 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 (subscriber, #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.
|
|||||||||||||