Global shortcut implementations

[justdie386]

Are there any plans to add the global shortcut? I saw it has been added to xdg-desktop-portal, and such a feature truly would be a life saver

[ilya-fedin]

Double that, the raw protocol seem to be very over-complicated and feels like would require a lot of effort to use directly

[GeorgesStavracas]

We're just missing someone motivated enough to implement it. This is naturally desirable for libportal to have.

[justdie386]

Alright, well if i ever come to figure out dbus then i'd be glad to help out, im just not sure where to start because dbus doesn't look very beginner friendly

[ilya-fedin]

We're just missing someone motivated enough to implement it.

That's understandable. I started looking at integrating libportal into a Qt application exactly because I'm not motivated enough to use raw global shortcut protocol, even via auto-generated XML->C++ bindings... That's sad to hear that no one else is interested and there will be no high level API in near future, though...

[justdie386]

While we are at it, does anyone know of any app that has been using those? Looking at its source code could make it easier for me to understand how this all works and how to use it

[ilya-fedin]

I don't think so. I was looking at KDE apps but they use KDE-specific protocol managed by their kglobalaccel daemon.

[justdie386]

Well there’s no way nobody ever used it, do we even know which xdg-desktop-portal-* supports global shortcuts

[ilya-fedin]

As far as I'm aware, only the KDE's portal backend implements it

[justdie386]

could seatd be viable until shortcuts are implemented? I couldn’t get any sort of keyboard stuff working with it because I couldn’t find any ezamples/docs but I’m pretty sure it can be used for this

[ilya-fedin]

You mean requesting access for raw devices with logind API?

[justdie386]

Yeah I guess, get access to keys that are currently pressed or something

[ilya-fedin]

I was thinking about that, yeah, the TakeDevice method of the org.freedesktop.login1.Session interface at org.freedesktop.login1 service which is at system D-Bus instance should perhaps provide it. But I'm doubt it will provide access to a process which is not the first one in the session...

[justdie386]

But seatd has libseat, which allows us to do that without root access, I just don’t know how to use it, there is an example but it doesn’t go really further than I’d like it to

[ilya-fedin]

I'm not sure what seatd and libseat are, AFAIK logind is responsible for it.

[ilya-fedin]

The most user-friendly way is perhaps checking whether the user is in input group and if not showing a dialog explaining additional permissions are needed, executing pkexec usermod -aG input $USER and requesting the user to re-login/reboot.

[justdie386]

Well indeed, this could actually be one way of doing this… but I really think something could be done with libseat

[justdie386]

Pretty sure sway uses it and other Wayland compositors too https://github.com/kennylevinsen/seatd

[ilya-fedin]

This? https://github.com/kennylevinsen/seatd/blob/master/include/seat.h#L49

[justdie386]

Yeah I’m pretty sure this lib provides enough stuff, I just don’t know how to use it and there is from what I found zero resources online outside of the repo on how to use it

[ilya-fedin]

its logind backend seem to use the TakeDevice method I described for open_device https://github.com/kennylevinsen/seatd/blob/master/libseat/backend/logind.c#L119

[ilya-fedin]

Yeah I’m pretty sure this lib provides enough stuff, I just don’t know how to use it and there is from what I found zero resources online outside of the repo on how to use it

I've linked to exact line in the header, look at it

[justdie386]

I really don’t know, I never touched low level stuff like that, I’m just planning to make higher level bindings for lua and use it

[justdie386]

Well I’m gonna look into it, try again with libseat maybe I’ll figure it out

[ilya-fedin]

I don't think this will work, I've tried to do the query with a D-Bus debugger and it has rejected because the process is not the session controller. The same will be for you if you're developing an application rather than a compositor.

[ilya-fedin]

IMO, there are three realistic ways:

1. KDE-specific: use the X API even when the application is running via native Wayland, just for global shortcuts, instruct users to enable the legacy X11 compatibility in Plasma settings
2. KDE+Qt-specific: use the kglobalaccel KDE framework
3. Add the user to input group to get access to the RAW devices without root and use any library for them. Qt has private classes to consume input from such device, either via raw evdev or via libinput (the difference is apparently in enumerating: raw /dev/input directory scanning vs getting the list & device info from libinput)

[justdie386]

well I could just make it require the user to be in input, or something I don’t know, but at least I know I’m not the only one struggling

[ManuelSchneid3r]

IMO, there are three realistic ways:

1. KDE-specific: use the X API even when the application is running via native Wayland, just for global shortcuts, instruct users to enable the legacy X11 compatibility in Plasma settings
2. KDE+Qt-specific: use the kglobalaccel KDE framework
3. Add the user to input group to get access to the RAW devices without root and use any library for them. Qt has private classes to consume input from such device, either via raw evdev or via libinput (the difference is apparently in enumerating: raw /dev/input directory scanning vs getting the list & device info from libinput)

The only proper way is to use the portal. None of these is generic and sustainable.

[ilya-fedin]

Sadly there's no one to make a high level/usable API so using work arounds is rendering more valuable and valuable with each new Wayland user

[ManuelSchneid3r]

None of these are is a workaround

1. Will break things
2. Adds heavy additional dependencies
3. Root required? Full input access? Really? Besides frameperfectness these kind of security measures are the reason we are going to through this exhausting transition to Wayland, right?

All of them will ultimately annoy users. None of them is a solution qualified enough for a project like this.

[ilya-fedin]

None of them is a solution qualified enough for a project like this.

I'm not sure what you mean by 'a project like this'. Those all are alternative ways instead of the portal for application developers.

1. Will break things

In my testing while it was working partially (and time has passed so maybe it's better now), nothing was broken.

2. Adds heavy additional dependencies

Not necessarily. For a Qt application, this adds almost nothing. Let's be realistically, this API is mostly needed for cross-platform applications which are written with either Qt or Electron/

3. Root required? Full input access? Really? Besides frameperfectness these kind of security measures are the reason we are going to through this exhausting transition to Wayland, right?

Still better than nothing (when no one provides a better implementation for applications).

[ilya-fedin]

To be clear, either of those 3 solutions are a few lines in application I work on and I won't be surprised if adding either of those will actually result in immediate increase of UX for end users. The only reason why I don't do this now is because this missing functionality seem to be unnoticed yet but as soon as it will get noticed and if libportal won't have implementation by that time, I'm likely to craft something of top of those solutions.

[ManuelSchneid3r]

'this project ' is libportal. As a future user of libportal I don't want any of these to happen. Probably I misunderstood you intentions because this post here is a feature request on getting the new portal implemented. not a some sort of discussion thread for your personal projects. Please, to save potential future volunteers time, no off topic.

[ilya-fedin]

@justdie386 and I were discussing other possible solutions given that portal implementation is not going to happen soon. I believe this discussion will be useful for other potential API users reaching this thread, to find other solutions until this API is implemented.