Kinto and Wayland Protocols

[tsujp]

I've seen various comments from other issues on this but this is more of a discussion.

WIth regards to getting this working with Wayland should we instead think about proposing an additional protocol for Wayland so that any compositor that implements the protocol can get similar behaviour?

The alternative is what other issues discuss around creating tools that happen to work on Wayland and do the same stuff.

I think the protocol approach would be a lot more portable and a solid contribution to Wayland. I'd like to offer my help in developing that if that's an approach we can take.

[rbreaves]

Oh if there’s a realistic way to interface w/ Wayland directly for the active app name then I’d love that as it definitely could provide what I’d need.

It’s my understanding that that is a security issue & that only DEs get that level of access - but how that works exactly I don’t know. If we can be just as direct & mostly ignore interfacing w/ the DE under Wayland then of course that’d lessen the work involved.

[tsujp]

I'll have to bring myself up to speed on Wayland protocols but as far as I know what we'd end up doing is defining the spec of the protocol and then if GNOME, KDE, etc implement that spec then that'd translate to what this does now but in a truly portable fashion.

So this wouldn't end up being a new program like it currently is for Xorg but a spec that the DE (which includes a compositor) uses.

[rbreaves]

Yea, I get what you are saying. I've never created a spec either for anything remotely like Wayland or a DE so I don't know what that spec would need to look like for them to take notice. My only concern is they may throw it out pretty quickly though if one of the tenets of Wayland is that it intentionally should not expose the active app or the window that has focus to anything but DE's.

If an acceptable protocol can be created for Wayland via dbus or whatever method then I would also like the ability to pass the actual window title name as well and not just the app equivalent to wm_class. The reason for that would be that I can see use cases for needing to know if a modal window or specific window within an app is open as well. RDP, VM and remote desktop apps in particular would benefit as the remote or guest session is something I try not to map from the host machine, but only the guest or destination.

Currently I simply disable all remappings for RDP and VM type apps to avoid double remapping because I can't dynamically update keymaps properly from a host when someone is on another system, so my recommendation is to install Kinto on the destination machines only, if at all possible.

[rbreaves]

To also mention interest from other similar projects to xkeysnail and this was that author's take https://github.com/snyball/Hawck/issues/6.

Waybind also looks interesting but no mechanism that I can see to bind per wm_class. arnarg/waybind#5

[DuMaM]

@rbreaves maybe you can try to give this a try? :)
https://github.com/samvel1024/kbct

[rbreaves]

@DuMaM You definitely got my hopes up for a second, but that application is no better than xkeysnail, the current underlying app that powers kinto.

Xkeysnail remaps just fine under Wayland already - what doesn't work is the app specific detection to update or change the remappings dynamically. As far as I know the only 2 solutions is to either have Wayland add a protocol as original discussed in this thread or add support for individual DEs to give up the name of the window that has current focus.

[alex-kinokon]

@rbreaves Do you want have any working code or branch we can try and test it out?

[rbreaves]

@proteriax asking if I have or want lol? I think I have a branch of xkeysnail that tested out an attempt but it’s not reliable. Fixing xkeysnail is the place to start - not Kinto. If xkeysnail gets fixed then so will Kinto!

[joshgoebel]

If someone has some code that even sort of works on Wayland (to detect window name/class) I'd love to see it. Definitely interested in seeing if Wayland support could be added to the keymapper. joshgoebel/keyszer#27

[sebastian-ruiz]

xremap claims support for application specific shortcuts. Would this work to add Wayland support?

[RedBearAK]

xremap claims support for application specific shortcuts. Would this work to add Wayland support?

Yes, and I used the xremap GNOME extension to create a working Wayland branch of keyszer. But it’s an inelegant mess and someone needs to come up with a better way to implement it. Xremap has also just added support for KDE Plasma. It should be possible to add that to keyszer as a supported desktop environment as well.

joshgoebel/keyszer#27

If your idea was to switch to xremap, it doesn’t support matching on the WM_NAME kind of property yet, and doesn’t have some of the other features keyszer now supports.

[mpldr]

if there’s a realistic way to interface w/ Wayland directly

Came here from the GitHub comment thread on this topic. Wayland as a protocol does not yet have support for it; the protocol is currently unstable. Accordingly support is currently not too great.

On the topic of how I did it in my script:

$ swaymsg -t get_tree | jq '.. | (.nodes? // empty)[] | select(.focused==true) | {app_id}'
{
  "app_id": "foot"
}