4 ms·

Wayland is the poster child for a rewrite that tries to be 'simple' and in doing so over-complicates things by under specification. Other commenters have mentio

Wayland is the poster child for a rewrite that tries to be 'simple' and in doing so over-complicates things by under specification. Other commenters have mentioned that usability extension issues but I wanted to discuss my experience as someone who maintains their own wayland client (for drawterm: https://github.com/9front/drawterm https://github.com/9front/drawterm). There are plenty of technical differences between how KDE, Gnome, and Wlroots that just cause more work for me. Perhaps most popularly Gnome is dying on the hill of "client side decorations", meaning that without mostly Gnome specific code you will get no title bar. KDE and Wlroots do upscaling different, KDE upscales with video in mind, Wlroots upscales with text in mind. There is no way to specify how a client would like this upscaling to be done, so to get consistent display you have to do the upscaling yourself. Some other minor annoyances include having to implement key repeat yourself, and no standard way for programs to cause a mouse movement. Like this article mentions I use wayland because it's the "only game in town", but after porting drawterm I became fairly unimpressed with the technical design.

slooonz 3y ago
> There is no way to specify how a client would like this upscaling to be done Isn’t it one of the points of content type hint ? (https://wayland.app/protocols/content-type-v1 https://wayland.app/protocols/content-type-v1)
- moody__ 3y ago
  It would certainly appear so, I would need to give it a try to know for sure. Based on the compositor support table on that page, this would be even more compositor specific logic as it seems exclusive to KWin. Thank you for the link though, this is the first I had seen someone mention this.
didntcheck 3y ago
And what's frustrating is this isn't just down to poor execution, it's fundamental to the design, and it was repeatedly pointed out from the start. I'm glad there's finally been some acknowledgement of issues predicted around a decade ago, but only because the issues have indeed manifested, making it a rather pyrrhic victory A "simple" solution to a necessary complex problem is just kicking the can down the road, and essentially asking everyone to invent their own incompatible wheels to fill in the missing bits. On X, there's enough flexibility for me to pick a DE and window manager separately, due to the standard modularization, whereas on Wayland, I have to check the compatibility of a screenshot tool with my desktop environment [1], and whether my DE even works with my graphics card! Everything becomes tightly coupled due to the lack of standards [1] unlike some I actually do support the move to not let any app read the screen or global KB input, but the interface for those that do should have been part of the Wayland project, not just "not our department!"
- noobermin 3y ago
  What is the solution here, if you don't mind me asking. I feel partial here to X, because it just "works", but as the article this cites, there are real issues to X and this afflicts the upstream developers, whom we need to develop our windowing system in the first place.
Zardoz84 3y ago
> key repeat yourself... now I understand why pressing "Supr" on Eclipse, doesn't repeat and removes anything more than a single character. Pretty anoying
vidarh 3y ago
I've warmed up to the idea that X11 needed a replacement after implementing (parts of) the protocol in Ruby (yes, I want to cause myself pain, clearly). It's obtuse in a way that might have made sense when first invented (e.g. slotting an arbitrary request byte in the request header for some requests because there's a free byte otherwise used for padding so that the request length can be 16-bit aligned) is just pointlessly stingy now. The way length fields and the lists the refer to might not be adjacent in a packet, likewise. But then I looked at the Render extension, and realised the problem was less the original protocol - it's easily extended after all - but that the people writing the extensions were so steeped in the same thinking of overgeneralising. E.g. the Render extension very sensibly - given we've mostly settled on a few formats - dictates a set of visuals that must be supported. Surely then they provide an easy way of obtaining it? No. You need to retrieve every single visual supported by the server. Surely the Render extension will just default to force clients to apply some godawful slow path if they want some bizarro format? No. But they'll at least make it easy to get the default formats everyone actually wants? No - you call a function that provides values for all the visual fields, such as depth, mask for red, green and blue bits and many other things, and then checks that mask and a bitfield determining whether you care about those things, against every single visual reported by the server. After seeing that - dozens of lines of code whose sole purpose is to work around the fact that the server extension written by the same people doesn't tell you the ids of the required visuals - I went looking at the Wayland spec in utter disgust. You could easily "fix" X in a aggressive but gradual way in a lot less time than Wayland - the biggest argument for Wayland is not technical, but not being mired in that culture, I thought. Only to find it's pretty much equally obtuse and overwrought, only in different ways... I expect to have to bite the bullet and move to Wayland eventually, but it feels very much like a lateral move with no upsides I care about and a lot of efforts that'll make me swear (I used bspwm, there's no port, so I'll need to figure out which of the tiling compositors are somewhat close enough, especially given I heavily rely on bspc to change bspwm's behaviour) and I'll resent every part of it. I really I wish we got a timeline where someone instead aggressively deprecated old functionality from Xorg in several rounds of purges.

slooonz 3y ago

> There is no way to specify how a client would like this upscaling to be done Isn’t it one of the points of content type hint ? (https://wayland.app/protocols/content-type-v1 https://wayland.app/protocols/content-type-v1)

moody__ 3y ago
It would certainly appear so, I would need to give it a try to know for sure. Based on the compositor support table on that page, this would be even more compositor specific logic as it seems exclusive to KWin. Thank you for the link though, this is the first I had seen someone mention this.

didntcheck 3y ago

And what's frustrating is this isn't just down to poor execution, it's fundamental to the design, and it was repeatedly pointed out from the start. I'm glad there's finally been some acknowledgement of issues predicted around a decade ago, but only because the issues have indeed manifested, making it a rather pyrrhic victory A "simple" solution to a necessary complex problem is just kicking the can down the road, and essentially asking everyone to invent their own incompatible wheels to fill in the missing bits. On X, there's enough flexibility for me to pick a DE and window manager separately, due to the standard modularization, whereas on Wayland, I have to check the compatibility of a screenshot tool with my desktop environment [1], and whether my DE even works with my graphics card! Everything becomes tightly coupled due to the lack of standards [1] unlike some I actually do support the move to not let any app read the screen or global KB input, but the interface for those that do should have been part of the Wayland project, not just "not our department!"

noobermin 3y ago
What is the solution here, if you don't mind me asking. I feel partial here to X, because it just "works", but as the article this cites, there are real issues to X and this afflicts the upstream developers, whom we need to develop our windowing system in the first place.

Zardoz84 3y ago

> key repeat yourself... now I understand why pressing "Supr" on Eclipse, doesn't repeat and removes anything more than a single character. Pretty anoying

vidarh 3y ago

I've warmed up to the idea that X11 needed a replacement after implementing (parts of) the protocol in Ruby (yes, I want to cause myself pain, clearly). It's obtuse in a way that might have made sense when first invented (e.g. slotting an arbitrary request byte in the request header for some requests because there's a free byte otherwise used for padding so that the request length can be 16-bit aligned) is just pointlessly stingy now. The way length fields and the lists the refer to might not be adjacent in a packet, likewise. But then I looked at the Render extension, and realised the problem was less the original protocol - it's easily extended after all - but that the people writing the extensions were so steeped in the same thinking of overgeneralising. E.g. the Render extension very sensibly - given we've mostly settled on a few formats - dictates a set of visuals that must be supported. Surely then they provide an easy way of obtaining it? No. You need to retrieve every single visual supported by the server. Surely the Render extension will just default to force clients to apply some godawful slow path if they want some bizarro format? No. But they'll at least make it easy to get the default formats everyone actually wants? No - you call a function that provides values for all the visual fields, such as depth, mask for red, green and blue bits and many other things, and then checks that mask and a bitfield determining whether you care about those things, against every single visual reported by the server. After seeing that - dozens of lines of code whose sole purpose is to work around the fact that the server extension written by the same people doesn't tell you the ids of the required visuals - I went looking at the Wayland spec in utter disgust. You could easily "fix" X in a aggressive but gradual way in a lot less time than Wayland - the biggest argument for Wayland is not technical, but not being mired in that culture, I thought. Only to find it's pretty much equally obtuse and overwrought, only in different ways... I expect to have to bite the bullet and move to Wayland eventually, but it feels very much like a lateral move with no upsides I care about and a lot of efforts that'll make me swear (I used bspwm, there's no port, so I'll need to figure out which of the tiling compositors are somewhat close enough, especially given I heavily rely on bspc to change bspwm's behaviour) and I'll resent every part of it. I really I wish we got a timeline where someone instead aggressively deprecated old functionality from Xorg in several rounds of purges.