Leon Henrik Plickat

I know exactly what you meant. But I would prefer to either implement this the right way, or not at all. And since we do not want riverctl to get...

I did not have the time and energy to work on this yet. If you want this feature, you'll need to do it yourself. It should be fairly straightforward.

@r4pr0n that `xdotool windowunmap` approach is insanely hacky, even for X. It is basically overriding the window management without properly communicating with the WM/Compositor, which is fragile and could easily...

> Wouldn't it also be possible to use the events in the respective wayland protocols? I think this may be the better approach. Although we may need to consider whom...

> Swallowing is in fact a vary simple feature [...] Nope, it really is not. It may *seem* simple from the perspective of a user, but if you want to...

Hey, before posting yet another "I also want this feature" comment, please make sure to ... 1. ... read all previous comments, especially those explaining why this proposed feature isn't...

A `PID Wayland window` connection is not something you can do correctly. Also, what if your terminal uses a client server model, like foot has? The new window is not...

> Implementation could probably be as simple as having a new property explicit output + some restoring logic on outputs change. I feel like this should be a list of...

```IRC [18:05:31] hmm... I don't think numlock state fits into the InputConfig abstraction... [18:06:16] [pkap] has quit [18:06:22] for one, InputConfig was designed for libinput configuration, where "not configured and...

Actually my comment was not critiquing the feature, I was just arguing that it doesn't fit into InputConfig. For the reasons listed as well as because for libinput input devices...