Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global shortcut implementations #134

Open
justdie386 opened this issue Dec 21, 2023 · 33 comments · May be fixed by #153
Open

Global shortcut implementations #134

justdie386 opened this issue Dec 21, 2023 · 33 comments · May be fixed by #153
Labels
enhancement New feature or request

Comments

@justdie386
Copy link

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
Copy link
Contributor

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

@GeorgesStavracas
Copy link
Member

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

@justdie386
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

justdie386 commented Dec 29, 2023

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
Copy link
Contributor

ilya-fedin commented Dec 30, 2023

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

@justdie386
Copy link
Author

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

@ilya-fedin
Copy link
Contributor

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

@justdie386
Copy link
Author

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
Copy link
Contributor

You mean requesting access for raw devices with logind API?

@justdie386
Copy link
Author

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

@ilya-fedin
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

ilya-fedin commented Dec 30, 2023

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

@ilya-fedin
Copy link
Contributor

ilya-fedin commented Dec 30, 2023

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
Copy link
Author

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

@justdie386
Copy link
Author

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

@ilya-fedin
Copy link
Contributor

@justdie386
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

justdie386 commented Dec 30, 2023

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

@ilya-fedin
Copy link
Contributor

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
Copy link
Contributor

ilya-fedin commented Dec 30, 2023

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
Copy link
Author

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
Copy link

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
Copy link
Contributor

ilya-fedin commented Jan 4, 2024

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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

ilya-fedin commented Apr 15, 2024

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
Copy link

'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
Copy link
Contributor

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

@TingPing TingPing added the enhancement New feature or request label Apr 27, 2024
@sonnyp sonnyp linked a pull request Jul 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants