4 ms·

>- Wine is unimplementable in Wayland. By design. This is a complicated issue which requires a lot of background to explain and answering it in full beyond my

>- Wine is unimplementable in Wayland. By design. This is a complicated issue which requires a lot of background to explain and answering it in full beyond my patience. >- Programs cannot set their own hotkeys in Wayland. This is a feature, not a bug. Why should clients be responsible for dealing with conflicts between programs that use the same hotkey? What if the user wants to pick a different hotkey? Add keylogging concerns on top of that and the argument for this feature becomes pretty weak. Programs designed with Wayland in mind provide some kind of executable that can be bound to a key in the compositor to interact with their daemon. >- Screenshotting and screen casting tools are unimplementable in Wayland, by design. This is a lie, or at least a falsehood born from ignorance. https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml https://github.com/swaywm/wlroots/blob/master/protocol/wlr-s... https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml https://github.com/swaywm/wlroots/blob/master/protocol/wlr-e... >These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation. A strong majority of Wayland compositors support these protocols, and talks are underway to improve the standardization process. >- I use the X forwarding feature so often that I have a hotkey on my laptop to open an Emacs frame running on my desktop (on my laptop's screen). Being able to jump between machines while keeping the entire session, incl. open and unsaved files, is pretty great. X forwarding still works with Xwayland. Nothing was broken - we have tools for backwards compatability where Wayland is still catching up. Desktops are complicated and it takes a long time and a lot of work to implement them. But no one is making you switch to Wayland. Keep using Xorg. I doubt you were going to switch anyway, the least you could do is stop spreading FUD.

ilikehurdles 8y ago
So wrt the hot key thing, is it possible to have window manager (or an application within an existing window manager) to allow control of window positions and sizes using keys? Something like xmonad, or Spectacle in OS X?
- Sir_Cmpwn 8y ago
  This is possible on sway, but no one has made standards for it yet (it would be pretty contentious, and some groundwork should probably be laid first). Sway implements the i3 IPC protocol, which has commands for moving windows around. You could bind this stuff to keys if you wish.
CyberShadow 8y ago
> This is a feature, not a bug. I think you have missed a few important points: - There is value in installing a program with a known set of hotkeys and having it work out-of-the-box. - The arguments apply to new software, but I'm not sure they justify the effort imposed on existing software. - Fragmentation is a big problem. There is a matrix of (number of Wayland implementations / API extension) x (number of software attempting to use Wayland protocol extensions), and gaps in this matrix result in non-working software and unhappy users. > What if the user wants to pick a different hotkey? What if the user wants to use a different font or color in the GUI? Reasonable software will have reasonable settings configurable; unreasonable software won't. In any case, this is a solved problem in other, even non-Linux desktop environments as well. > Add keylogging concerns on top of that How strong are the keylogging concerns? An effective keylogger needs to either listen to keystrokes passively, or capture then retranslate them. Wouldn't allowing programs to assign hotkeys but not allowing them to emit keyboard events solve this issue? > This is a lie, or at least a falsehood born from ignorance. Correct me if I'm wrong, but the links you provided seem to describe a protocol extension. I believe I was unambiguous in that I specifically mentioned Wayland, not a particular implementation. > A strong majority of Wayland compositors support these protocols, and talks are underway to improve the standardization process. Standardization is good, but until this becomes a reality, I believe the criticisms stand, and it would be unfair to dismiss them. > But no one is making you switch to Wayland. Keep using Xorg. I doubt you were going to switch anyway, the least you could do is stop spreading FUD. Nice to see you taking this so well.
- Sir_Cmpwn 8y ago
  >- There is value in installing a program with a known set of hotkeys and having it work out-of-the-box. It's a matter of taste, and ours differ. Regardless, there has been some discussion about hotkey protocols. I encourage you to participate. >What if the user wants to use a different font or color in the GUI? Reasonable software will have reasonable settings configurable; unreasonable software won't. In any case, this is a solved problem in other, even non-Linux desktop environments as well. Wayland compositors aren't responsible for choosing the color of your buttons. They are responsible for dispatching keyboard events, however. >How strong are the keylogging concerns? An effective keylogger needs to either listen to keystrokes passively, or capture then retranslate them. Wouldn't allowing programs to assign hotkeys but not allowing them to emit keyboard events solve this issue? Perhaps! You should bring this up when you start the discussion. >Correct me if I'm wrong, but the links you provided seem to describe a protocol extension. I believe I was unambiguous in that I specifically mentioned Wayland, not a particular implementation. Another thing Wayland doesn't define: application windows. The core Wayland protocol is very conservative, and protocol extensions are necessary for doing anything useful. >Standardization is good, but until this becomes a reality, I believe the criticisms stand, and it would be unfair to dismiss them. There are effective standards which are implemented by many compositors and clients. In my opinion this is good enough to dispell criticism, but we're trying to improve further still.

ilikehurdles 8y ago

So wrt the hot key thing, is it possible to have window manager (or an application within an existing window manager) to allow control of window positions and sizes using keys? Something like xmonad, or Spectacle in OS X?

Sir_Cmpwn 8y ago
This is possible on sway, but no one has made standards for it yet (it would be pretty contentious, and some groundwork should probably be laid first). Sway implements the i3 IPC protocol, which has commands for moving windows around. You could bind this stuff to keys if you wish.

CyberShadow 8y ago

> This is a feature, not a bug. I think you have missed a few important points: - There is value in installing a program with a known set of hotkeys and having it work out-of-the-box. - The arguments apply to new software, but I'm not sure they justify the effort imposed on existing software. - Fragmentation is a big problem. There is a matrix of (number of Wayland implementations / API extension) x (number of software attempting to use Wayland protocol extensions), and gaps in this matrix result in non-working software and unhappy users. > What if the user wants to pick a different hotkey? What if the user wants to use a different font or color in the GUI? Reasonable software will have reasonable settings configurable; unreasonable software won't. In any case, this is a solved problem in other, even non-Linux desktop environments as well. > Add keylogging concerns on top of that How strong are the keylogging concerns? An effective keylogger needs to either listen to keystrokes passively, or capture then retranslate them. Wouldn't allowing programs to assign hotkeys but not allowing them to emit keyboard events solve this issue? > This is a lie, or at least a falsehood born from ignorance. Correct me if I'm wrong, but the links you provided seem to describe a protocol extension. I believe I was unambiguous in that I specifically mentioned Wayland, not a particular implementation. > A strong majority of Wayland compositors support these protocols, and talks are underway to improve the standardization process. Standardization is good, but until this becomes a reality, I believe the criticisms stand, and it would be unfair to dismiss them. > But no one is making you switch to Wayland. Keep using Xorg. I doubt you were going to switch anyway, the least you could do is stop spreading FUD. Nice to see you taking this so well.

Sir_Cmpwn 8y ago
>- There is value in installing a program with a known set of hotkeys and having it work out-of-the-box. It's a matter of taste, and ours differ. Regardless, there has been some discussion about hotkey protocols. I encourage you to participate. >What if the user wants to use a different font or color in the GUI? Reasonable software will have reasonable settings configurable; unreasonable software won't. In any case, this is a solved problem in other, even non-Linux desktop environments as well. Wayland compositors aren't responsible for choosing the color of your buttons. They are responsible for dispatching keyboard events, however. >How strong are the keylogging concerns? An effective keylogger needs to either listen to keystrokes passively, or capture then retranslate them. Wouldn't allowing programs to assign hotkeys but not allowing them to emit keyboard events solve this issue? Perhaps! You should bring this up when you start the discussion. >Correct me if I'm wrong, but the links you provided seem to describe a protocol extension. I believe I was unambiguous in that I specifically mentioned Wayland, not a particular implementation. Another thing Wayland doesn't define: application windows. The core Wayland protocol is very conservative, and protocol extensions are necessary for doing anything useful. >Standardization is good, but until this becomes a reality, I believe the criticisms stand, and it would be unfair to dismiss them. There are effective standards which are implemented by many compositors and clients. In my opinion this is good enough to dispell criticism, but we're trying to improve further still.