5 ms·

> 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 havin

> 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.
- mcguire 8y ago
  "Another thing Wayland doesn't define: application windows. The core Wayland protocol is very conservative, and protocol extensions are necessary for doing anything useful." ? Could you explain that further? I haven't followed wayland much?
  - Sir_Cmpwn 8y ago
    There's a widely supported protocol extension called xdg-shell which is used for desktop application windows: https://github.com/wayland-project/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml https://github.com/wayland-project/wayland-protocols/blob/ma...
    - hedora 8y ago
      It sounds like, for wayland to actually be usable, you need to define protocol extensions that bring it to feature parity with X11. At that point, why not just deprecate and replace the two(?) things that are problematic with X11: the keyboard logging protocol, and lack of access control on screenshots? Surely, that is easier than reimplementing the entire graphics stack, all window managers, and all applications.
      - Sir_Cmpwn 8y ago
        Because X11 is a huge dumpster fire that no one wants to maintain. How would you feel about maintaining a 30 year old legacy piece of software which has changed hands 5-6 times since its inception? Wayland is truly a better design and everyone is in favor of leaving that codebase behind.
  - seba_dos1 8y ago
    Generally, core Wayland is very minimal. It's meant to have only the pieces that are essential for every Wayland implementation, not just desktop window managers. Therefore you have xdg-shell extension which is meant for desktop and its windows, you have ivi-shell which is meant for automotive applications and you can have your own extension if your use case is different enough to need it. Thanks to that, KDE and GNOME don't have to implement any IVI stuff and cars don't have to know how to minimize or maximize a window, which, as a concept, might not even really exist there.
sapphire_tomb 8y ago
>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? That would (for me at least) break my favourite password manager KeePass, which has a Global Hotkey for "autotype" of passwords.

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.

mcguire 8y ago
"Another thing Wayland doesn't define: application windows. The core Wayland protocol is very conservative, and protocol extensions are necessary for doing anything useful." ? Could you explain that further? I haven't followed wayland much?
- Sir_Cmpwn 8y ago
  There's a widely supported protocol extension called xdg-shell which is used for desktop application windows: https://github.com/wayland-project/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml https://github.com/wayland-project/wayland-protocols/blob/ma...
  - hedora 8y ago
    It sounds like, for wayland to actually be usable, you need to define protocol extensions that bring it to feature parity with X11. At that point, why not just deprecate and replace the two(?) things that are problematic with X11: the keyboard logging protocol, and lack of access control on screenshots? Surely, that is easier than reimplementing the entire graphics stack, all window managers, and all applications.
    - Sir_Cmpwn 8y ago
      Because X11 is a huge dumpster fire that no one wants to maintain. How would you feel about maintaining a 30 year old legacy piece of software which has changed hands 5-6 times since its inception? Wayland is truly a better design and everyone is in favor of leaving that codebase behind.
- seba_dos1 8y ago
  Generally, core Wayland is very minimal. It's meant to have only the pieces that are essential for every Wayland implementation, not just desktop window managers. Therefore you have xdg-shell extension which is meant for desktop and its windows, you have ivi-shell which is meant for automotive applications and you can have your own extension if your use case is different enough to need it. Thanks to that, KDE and GNOME don't have to implement any IVI stuff and cars don't have to know how to minimize or maximize a window, which, as a concept, might not even really exist there.

sapphire_tomb 8y ago

>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? That would (for me at least) break my favourite password manager KeePass, which has a Global Hotkey for "autotype" of passwords.