flatpak
Global shortcut implementations
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
Double that, the raw protocol seem to be very over-complicated and feels like would require a lot of effort to use directly
We're just missing someone motivated enough to implement it. This is naturally desirable for libportal to have.
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
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...
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
I don't think so. I was looking at KDE apps but they use KDE-specific protocol managed by their kglobalaccel daemon.
Well there’s no way nobody ever used it, do we even know which xdg-desktop-portal-* supports global shortcuts
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
Yeah I guess, get access to keys that are currently pressed or something
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...
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
I'm not sure what seatd and libseat are, AFAIK logind is responsible for it.
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.
Well indeed, this could actually be one way of doing this… but I really think something could be done with libseat
Pretty sure sway uses it and other Wayland compositors too https://github.com/kennylevinsen/seatd
This? https://github.com/kennylevinsen/seatd/blob/master/include/seat.h#L49
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
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
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
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
Well I’m gonna look into it, try again with libseat maybe I’ll figure it out
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.
IMO, there are three realistic ways:
- 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
- KDE+Qt-specific: use the kglobalaccel KDE framework
- 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)
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
IMO, there are three realistic ways:
- 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
- KDE+Qt-specific: use the kglobalaccel KDE framework
- 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.
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
None of these are is a workaround
- Will break things
- Adds heavy additional dependencies
- 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.
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).