This is false. Wine could be implemented, it would just be less easy than on X11 because it uses relative coordinates for everything. But it's totally possible to convert absolute coords to relative coords and use e.g. wl_subsurface.
>Programs cannot set their own hotkeys in Wayland. You must use the desktop enviromnent's hotkey tool to set global hotkeys.
Yes. This is by design, because it's very easy to turn a global hotkey mechanism into a keylogger mechanism. Also it's not clear how hotkey conflicts should be handled.
Note that there are protocol proposals for global hotkeys.
>Screenshotting and screen casting tools are unimplementable in Wayland, by design.
They already work. See xdg-desktop-portal.
> Some Wayland implementations provide additional features, like screenshotting / hotkey registration, anyway, as API extensions. These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation.
That's how it works. Wayland doesn't have the magical power to make everybody implement a common interface. For an interface to be implemented, compositor writers and desktop developers have to agree on a design. Drew DeVault said on IRC something that sums up the situation quite well: "Asking wayland for hotkey management is like asking the HTTP standards group for a new HTML element".
Is the information in this bug outdated?
https://bugs.winehq.org/show_bug.cgi?id=42284
> Yes. This is by design, because it's very easy to turn a global hotkey mechanism into a keylogger mechanism. Also it's not clear how hotkey conflicts should be handled.
It doesn't change that this impacts usability, and a lot of software will need significant updates to accommodate these limitations.
> They already work. See xdg-desktop-portal.
As I understand, xdg-desktop-portal is one competing mechanism among several.
> That's how it works. Wayland doesn't have the magical power to make everybody implement a common interface.
I don't understand... by "a common interface", how would that differ in concept from the X11 protocol?
This comment suggests the same thing as me: https://bugs.winehq.org/show_bug.cgi?id=42284#c8
> It doesn't change that this impacts usability, and a lot of software will need significant updates to accommodate these limitations.
Yes, software needs to be updated to work with Wayland. Though, I'm not personally using a lot of software having global hotkeys, and I can configure global hotkeys in my compositor when needed.
> As I understand, xdg-desktop-portal is one competing mechanism among several.
It's the most widely supported mechanism. Works on GNOME and KDE, and support for Sway (and more generally wlroots) is WIP.
> I don't understand... by "a common interface", how would that differ in concept from the X11 protocol?
In the X11 world, all WMs didn't have to agree on a screen capture protocol.
Note that there are discussions in progress to improve communication between Wayland compositor writers.
It sounds like there is no equivalent of HTML though, and X used to provide an HTML-level API for which there is now no standard. It's a pretty fair criticism of Wayland if it requires developers to re-invent a common interface to get functionality that was previously available through X.
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-s...
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.
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.
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.
?
Could you explain that further? I haven't followed wayland much?
https://github.com/wayland-project/wayland-protocols/blob/ma...
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.
That would (for me at least) break my favourite password manager KeePass, which has a Global Hotkey for "autotype" of passwords.
Sway implements the i3 IPC protocol, which has commands for moving windows around. You could bind this stuff to keys if you wish.
What, why?
> Screenshotting and screen casting tools are unimplementable in Wayland, by design.
They're not implementable without specific privileges or protocols and that is a very good thing. I don't want my calculator app to be able to record eveything on my screen.
> I use the X forwarding feature so often that I have a hotkey on my laptop
This seems like your very specific use case (and wouldn't be impossible in Wayland).
i don't think this is true...i'm pretty sure i've screenshotted desktops before when using GNOME on Wayland.
Here is some discussion in Wine's bugtracker: https://bugs.winehq.org/show_bug.cgi?id=42284
There's a similar problem with implementing X on top of Wayland, and so XWayland has special powers that normal apps don't in order to be able to work. That's why running Wine as an X client under XWayland doesn't have this problem.
> It is part of their concept that applications should not have control over the window position and similar settings.
> I can understand this for security relevant features, like grabbing the keyboard and mouse input from another window, but not for things like specifying the window position
Seems excessive
And yes, I use i3, so I am a fan of tiling windomanagers too. Not everything nicely fits into such a box though, and it's better err on the side of compatibility here, than say, can't use that app, sorry
That way those java apps would still work, right?
It still can, the client merely gives size hints. It is entirely up to the window manager whether it honours them.
From what I've seen, Wayland seems to follow a very narrow set of use cases, and willfully ignores others outside its philosophy, no matter what their practical applications might be.
From what I remember reading previously:
- Wine is unimplementable in Wayland. By design.
- Programs cannot set their own hotkeys in Wayland. You must use the desktop enviromnent's hotkey tool to set global hotkeys. (Desktop enviroments may provide APIs for this, but then you get the foreseeable issues with using e.g. KDE apps on Gnome. And what if you don't want a desktop "environment"?)
- Screenshotting and screen casting tools are unimplementable in Wayland, by design.
- Some Wayland implementations provide additional features, like screenshotting / hotkey registration, anyway, as API extensions. These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation.
- 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.
I can certainly think of situations where Wayland's advantages greatly outweigh its drawbacks, but its philosophy seems so much at odds with at least the way I interact with my computer, that the idea of switching to Wayland seems completely unfathomable. As far as I can see, at this rate, Xorg will live forever.
I've been instead working on my own little tool to fix the few annoyances in Xorg clients that I ran into (the ease with which I've achieved this and the flexibility of the tool speaks further in Xorg's favor):
https://github.com/CyberShadow/hax11