5 ms·

Now days Wayland compatible DEs seems to support everything the average user needs while supporting quite a few modern features that were apparently too diffic

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.
    - canofbars 6y ago
      >a notification daemon that creates a notification bubble at some part of the screen The DE comes with one, you just send your notification to it. Apps creating their own notification bubbles is an anti feature and should be prevented if possible. They don't show in the notification box/ on the lock screen and ignore your do not disturb setting. >a toolbar of some sorts that sits at a specific place on the screen and is summoned on command Put the toolbar inside the app window or make it a new window and let the user decide where it goes. Apps being able to draw over the screen should probably be provided as a root feature as it is pretty dangerous left exposed. >a collapsible terminal application that summons itself on a certain global hotkey and otherwise lays hidden I just checked and gnome allows launching programs via shortcuts. An app should not be able to passively sit in the background collecting keystrokes to launch itself. This is a massive security risk >a program that rearranges other windows for any particular purpose such as tiling them in a specific way that the user wants The window manager implements wayland and is free to arrange windows however it wants as it is a trusted component. Basically all of the stuff in your comment is achievable via the DE/WM. Its a good thing that programs no longer have free reign to do whatever they want and passively record the users keyboard, screen and draw over anything.
      - Blikkentrekker 6y ago
        > The DE comes with one, you just send your notification to it. Apps creating their own notification bubbles is an anti feature and should be prevented if possible. They don't show in the notification box/ on the lock screen and ignore your do not disturb setting. And what if you don't like the one the compositor comes with and want to use a different one? Pantheon, XFCE, Mate and many other systems by design run their notification daemon as a separate process that can be disabled so that the user may choose what he wishes; there are also many standalone notification daemons to fill this gap. > Put the toolbar inside the app window or make it a new window and let the user decide where it goes. Apps being able to draw over the screen should probably be provided as a root feature as it is pretty dangerous left exposed. I mean a global toolbar at the bottom or top of the screen. > I just checked and gnome allows launching programs via shortcuts. An app should not be able to passively sit in the background collecting keystrokes to launch itself. This is a massive security risk It's a “security risk” of a far lesser magnitude than “an application can read and write all data owned by your user”. It's silly to remove features because processes that run with your user's rights have the ability to fuck you up. Might we remove the rm utility now because it's a security risk that it can unlink files? > The window manager implements wayland and is free to arrange windows however it wants as it is a trusted component. And what if it not do so as the user wishes to and the user wishes to use something else to do it? This is why X11 eventually evolved the EWMH standard to allow the window manager and a third program to coöperate without conflict on this. > Basically all of the stuff in your comment is achievable via the DE/WM. Its a good thing that programs no longer have free reign to do whatever they want and passively record the users keyboard, screen and draw over anything. Everything is achievable if it be built in to the compositor including fully fledged video games and web browsers. The reason we have such a thing as software is because the compositor won't have all those things we want, and if it did for every single user, then it would be so bloated beyond belief. The Wayland solution to missing features is “the compositor should do it”, but no compositor has all these features; that is why software exists, and that is why one often writes one's own software.

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.
  - canofbars 6y ago
    >a notification daemon that creates a notification bubble at some part of the screen The DE comes with one, you just send your notification to it. Apps creating their own notification bubbles is an anti feature and should be prevented if possible. They don't show in the notification box/ on the lock screen and ignore your do not disturb setting. >a toolbar of some sorts that sits at a specific place on the screen and is summoned on command Put the toolbar inside the app window or make it a new window and let the user decide where it goes. Apps being able to draw over the screen should probably be provided as a root feature as it is pretty dangerous left exposed. >a collapsible terminal application that summons itself on a certain global hotkey and otherwise lays hidden I just checked and gnome allows launching programs via shortcuts. An app should not be able to passively sit in the background collecting keystrokes to launch itself. This is a massive security risk >a program that rearranges other windows for any particular purpose such as tiling them in a specific way that the user wants The window manager implements wayland and is free to arrange windows however it wants as it is a trusted component. Basically all of the stuff in your comment is achievable via the DE/WM. Its a good thing that programs no longer have free reign to do whatever they want and passively record the users keyboard, screen and draw over anything.
    - Blikkentrekker 6y ago
      > The DE comes with one, you just send your notification to it. Apps creating their own notification bubbles is an anti feature and should be prevented if possible. They don't show in the notification box/ on the lock screen and ignore your do not disturb setting. And what if you don't like the one the compositor comes with and want to use a different one? Pantheon, XFCE, Mate and many other systems by design run their notification daemon as a separate process that can be disabled so that the user may choose what he wishes; there are also many standalone notification daemons to fill this gap. > Put the toolbar inside the app window or make it a new window and let the user decide where it goes. Apps being able to draw over the screen should probably be provided as a root feature as it is pretty dangerous left exposed. I mean a global toolbar at the bottom or top of the screen. > I just checked and gnome allows launching programs via shortcuts. An app should not be able to passively sit in the background collecting keystrokes to launch itself. This is a massive security risk It's a “security risk” of a far lesser magnitude than “an application can read and write all data owned by your user”. It's silly to remove features because processes that run with your user's rights have the ability to fuck you up. Might we remove the rm utility now because it's a security risk that it can unlink files? > The window manager implements wayland and is free to arrange windows however it wants as it is a trusted component. And what if it not do so as the user wishes to and the user wishes to use something else to do it? This is why X11 eventually evolved the EWMH standard to allow the window manager and a third program to coöperate without conflict on this. > Basically all of the stuff in your comment is achievable via the DE/WM. Its a good thing that programs no longer have free reign to do whatever they want and passively record the users keyboard, screen and draw over anything. Everything is achievable if it be built in to the compositor including fully fledged video games and web browsers. The reason we have such a thing as software is because the compositor won't have all those things we want, and if it did for every single user, then it would be so bloated beyond belief. The Wayland solution to missing features is “the compositor should do it”, but no compositor has all these features; that is why software exists, and that is why one often writes one's own software.