3 ms·

Well, when Wayland started they went in on the assumption that they could cast away quite a bit that “no one was using” or that “wasn't necessary”. And then th

Well, when Wayland started they went in on the assumption that they could cast away quite a bit that “no one was using” or that “wasn't necessary”. And then they had to include more of what they cast away because they underestimated the number of consumers of things they personally weren't using. libinput originally actually did not have a way to disable and configure pointer acceleration I believe because the developed thought there was no reason to ever turn it off. He was not a gamer and was largely ignorant of how essential being able to disable it is for the level of accuracy required for video games.

SulfurHexaFluri 6y ago
Now days Wayland compatible DEs seems to support everything the average user needs while supporting quite a few modern features that were apparently too difficult to support in X11 like monitors with different DPI scales.
- Blikkentrekker 6y ago
  That you think that would suggest you have a similar lack of appreciation of what users that aren't you need that the developers that went into it had. At this point Wine is still at the point of not considering a Wayland port until some severe changes happen at all — it cannot even begin to map the WinAPI to Wayland as it could to X11 at this point because too many features they need are missing that the developers didn't consider would be necessary for many things that Windows simply exposes. https://bugs.winehq.org/show_bug.cgi?id=42284#c1 https://bugs.winehq.org/show_bug.cgi?id=42284#c1 It's from 2017 but it details some of the features that they would need which Wayland does not consider to support.
  - SulfurHexaFluri 6y ago
    The wine situation is kind of unique. Programs should not be able to force their locations, the wayland devs are correct here. The unique issue is trying to map windows apis to wayland. The wine devs are pushing to have wayland implement all of the mistakes in the windows API while the wayland devs want the best possible solution without being chained to the windows api. I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues. In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications.
    - Blikkentrekker 6y ago
      > The wine situation is kind of unique. Programs should not be able to force their locations, the wayland devs are correct here. Absolutely not. This is needed for many things, and that you think it can simply be stripped shows your lack of appreciation of the needs of many other users and software. How will you without this for instance make: - a notification daemon that creates a notification bubble at some part of the screen - a toolbar of some sorts that sits at a specific place on the screen and is summoned on command - a collapsible terminal application that summons itself on a certain global hotkey and otherwise lays hidden - any such application that summons itself - a program that rearranges other windows for any particular purpose such as tiling them in a specific way that the user wants All these things obviously exist as of this moment, and are used by many users, and can't be made to work on Wayland because the developers were “correct” according to you in their assumption that none might ever need this. > I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues. Your conviction would be wrong; I've been in the same situation and talked to the Wayland developers and it is they who refuse to implement various features that are highly requæsted based on principle. > In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications. Yes, if it would be only Wine, perhaps, but it's not only Wine — and that you think it's only Wine shows either having never researched the mountain of issues, or willfully ignoring them because these concerns are immediately encountered when researching the issue of developers of many an application who are not pleased that their application fundamentally can't work on Wayland because it endeavored to not include basic functionality that every other display protocol has. These were not “mistakes” — the reason everything from Windows, to X11, to Quartz has these features is because users need them for what they wish to do. And this is only about programs choosing the positions of their own windows. A simple, trivial other thing is every time a new Hearthstone expansion comes out and I buy about 80 new packs with in-game currency that I game insists that I sit through the animations of opening them which bores me. I refuse and rather simply minimize the Hearthstone window and even though it doesn't have focus rapidly send it endless spacebar key events with a trivial xdotool command which then does this in about 15 minutes without needing my attention — such a simple thing cannot be done in Wayland at the moment and most likely never will because “users should not be able to simulate key events” as far as the Wayland developers are concerned, which is obviously a function with many use cases. “Users should not be able to ...” was the mantra of the Wayland developers when they started, and in many cases they have relented and allowed them because they realized they severely underestimated for how many things users do need to do that.
kaba0 6y ago
Wayland is a display protocol, and the base of that protocol is deliberately really minimalistic - it’s there so different programs understanding the protocol can draw their rectangular windows on to the screen and that’s it. But Wayland developers did think of additional requirements but were thinking that ad hoc inventing something that may or may not be implemented downstream would be a bad idea (it is), so they created a standard way of adding extensions to the base protocol - which are created with cooperation between major desktop environments - the actual implementers of said protocols. And as of now, wayland is pretty feature-compatible with x, in an actually extendable way (much more close to the UNIX philosophy if that’s your thing).

SulfurHexaFluri 6y ago

Now days Wayland compatible DEs seems to support everything the average user needs while supporting quite a few modern features that were apparently too difficult to support in X11 like monitors with different DPI scales.

Blikkentrekker 6y ago
That you think that would suggest you have a similar lack of appreciation of what users that aren't you need that the developers that went into it had. At this point Wine is still at the point of not considering a Wayland port until some severe changes happen at all — it cannot even begin to map the WinAPI to Wayland as it could to X11 at this point because too many features they need are missing that the developers didn't consider would be necessary for many things that Windows simply exposes. https://bugs.winehq.org/show_bug.cgi?id=42284#c1 https://bugs.winehq.org/show_bug.cgi?id=42284#c1 It's from 2017 but it details some of the features that they would need which Wayland does not consider to support.
- SulfurHexaFluri 6y ago
  The wine situation is kind of unique. Programs should not be able to force their locations, the wayland devs are correct here. The unique issue is trying to map windows apis to wayland. The wine devs are pushing to have wayland implement all of the mistakes in the windows API while the wayland devs want the best possible solution without being chained to the windows api. I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues. In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications.
  - Blikkentrekker 6y ago
    > The wine situation is kind of unique. Programs should not be able to force their locations, the wayland devs are correct here. Absolutely not. This is needed for many things, and that you think it can simply be stripped shows your lack of appreciation of the needs of many other users and software. How will you without this for instance make: - a notification daemon that creates a notification bubble at some part of the screen - a toolbar of some sorts that sits at a specific place on the screen and is summoned on command - a collapsible terminal application that summons itself on a certain global hotkey and otherwise lays hidden - any such application that summons itself - a program that rearranges other windows for any particular purpose such as tiling them in a specific way that the user wants All these things obviously exist as of this moment, and are used by many users, and can't be made to work on Wayland because the developers were “correct” according to you in their assumption that none might ever need this. > I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues. Your conviction would be wrong; I've been in the same situation and talked to the Wayland developers and it is they who refuse to implement various features that are highly requæsted based on principle. > In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications. Yes, if it would be only Wine, perhaps, but it's not only Wine — and that you think it's only Wine shows either having never researched the mountain of issues, or willfully ignoring them because these concerns are immediately encountered when researching the issue of developers of many an application who are not pleased that their application fundamentally can't work on Wayland because it endeavored to not include basic functionality that every other display protocol has. These were not “mistakes” — the reason everything from Windows, to X11, to Quartz has these features is because users need them for what they wish to do. And this is only about programs choosing the positions of their own windows. A simple, trivial other thing is every time a new Hearthstone expansion comes out and I buy about 80 new packs with in-game currency that I game insists that I sit through the animations of opening them which bores me. I refuse and rather simply minimize the Hearthstone window and even though it doesn't have focus rapidly send it endless spacebar key events with a trivial xdotool command which then does this in about 15 minutes without needing my attention — such a simple thing cannot be done in Wayland at the moment and most likely never will because “users should not be able to simulate key events” as far as the Wayland developers are concerned, which is obviously a function with many use cases. “Users should not be able to ...” was the mantra of the Wayland developers when they started, and in many cases they have relented and allowed them because they realized they severely underestimated for how many things users do need to do that.

kaba0 6y ago

Wayland is a display protocol, and the base of that protocol is deliberately really minimalistic - it’s there so different programs understanding the protocol can draw their rectangular windows on to the screen and that’s it. But Wayland developers did think of additional requirements but were thinking that ad hoc inventing something that may or may not be implemented downstream would be a bad idea (it is), so they created a standard way of adding extensions to the base protocol - which are created with cooperation between major desktop environments - the actual implementers of said protocols. And as of now, wayland is pretty feature-compatible with x, in an actually extendable way (much more close to the UNIX philosophy if that’s your thing).