Hacker News Reader

>Wine is unimplementable in Wayland. By design.

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".

> This is false. Wine could be implemented, [...]

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?

> Is the information in this bug outdated?

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.

A new common interface can be better designed and take security levels, permissions, ... into account, instead of giving everything access to all windows?

> Asking wayland for hotkey management is like asking the HTTP standards group for a new HTML element

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.

I think sway just got support for relative coordinates.

Sway got support for relative-pointer, but it's unrelated to positioning surfaces.

I see, my mistake.

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

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

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

"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?

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.

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/ma...

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.

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.

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

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?

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.

> Wine is unimplementable in Wayland. By design.

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).

> Screenshotting and screen casting tools are unimplementable in Wayland, by design

i don't think this is true...i'm pretty sure i've screenshotted desktops before when using GNOME on Wayland.

Those tools were likely not using Wayland protocol APIs, but extensions specific to the desktop environment you were using.

Could you expand on why Wine is unimplementable in Wayland?

Essentially because many Windows APIs are unimplementable in Wayland.

Here is some discussion in Wine's bugtracker: https://bugs.winehq.org/show_bug.cgi?id=42284

One complaint in this specific thread is that applications can't control the location of their surfaces (which is needed for things like drop-downs and tool tips), but then again sub-surfaces can be controlled by the parent surface. This specific problem does look solveable.

As I understand it from that bug report, the problem is that the Windows app doesn't have to provide any link between the menu or tooltip and the window it's from that's visible to Wine. So your solution basically boils down to modifying every Windows app out there to make it Wayland-compatible, potentially including a bunch of niche industry-specific or even company-specific ones.

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.

> One problem is for example that a program can not specify the location of a newly created window.

> 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

As a user and big fan of tiling window managers, I want the window manager to be the one deciding where windows are positioned, not the application that owns the window. But hey, we can have different tastes and preferences.

That's fine for the majority of Linux apps, but being so strict could impact cross-platform apps that don't understand those assumptions, and then they don't work well at all. For example, the interactive brokers Java application is written in a cross-platform way that makes use of many popup menus. I would hate my choice of wm saying, no, you cannot effectively use this software because it doesn't conform to our windowing constraints.

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

In those cases, why not just have the window manager lie to the application and say, effectively, "your request to position the window at the coordinates you specify has been fulfilled", but actually position the window where the window manager wants?

That way those java apps would still work, right?

Sure, if it actually works

> I want the window manager to be the one deciding where windows are positioned

It still can, the client merely gives size hints. It is entirely up to the window manager whether it honours them.