QHotkey
QHotkey copied to clipboard
Skycoder42
Common base library?
Hi @Skycoder42, I'm a new user of your library. I implemented native hotkeys for albertlauncher before. I know how hard it is to get things right. There are dozens of hotkey libs around but none of them does the job well. Probably because of lacking manpower. Especially when it comes to Wayland. This is extremely frustrating for users (devs) and end users of the apps.
This is an issue I want to address with the idea of a common library with a C interface (implementation would have to be C/C++/ObjC anyway). A generalized libhotkey so to say. Language/Framework (e.g. C++ (exceptions!)/Python/Qt) bindings can be built on top of it.
We could work together and there are standalone app devs who would join for sure (already talked with zeal and copyq devs about this idea). In the end we hopefully can get things right and make our lives a ton easier.
Let me know what you think about it.
Hi @ManuelSchneid3r - I am currently not actively working on this project, however, I have appointed @Shatur as Maintainer of this repository, maybe he would be interested in helping
This is an issue I want to address with the idea of a common library with a C interface (implementation would have to be C/C++/ObjC anyway).
Sounds like a great idea, but I don't have time to participate in development. But I would happy to reuse it in QHotkey.
No, I just don't have a time to work on a completely new implementation of a new shortcut library. But as I said - I would happy to reuse it here.
It should not be that much of work right? The code is there. Just some redirections, a new api, most of the work is cmake I guess.
It should not be that much of work right?
If it were that simple, the implementation would already be in there. You said yourself There are dozens of hotkey libs around but none of them does the job well. Probably because of lacking manpower.
It is the exact idea to have less work. The system APIs are unique (winapi, Cocoa, xcb, xliband potentially Wayland stuff) so there is only one way implement it. QHotkey does a lot of it. We just have to split QHotkey in its Qt api and the low level code. From there on you can you can only profit because several ppl work on libhotkey. The more bindings we have (Qt, native C++, Python etc) the more man power flows into this (ugly, error-prone part of the) project.
The most meat is in the mapping of keys. It makes sense to have one peer reviewed one
QHotkey does a lot of it. We just have to split QHotkey in its Qt api and the low level code. rom there on you can you can only profit because several ppl work on libhotkey.
In practice it rarely works this way :( I split out the translation engine from my translator into a separate library, but I only had contributors because of the main translation app. The same happened with ksnip, here is even my issue where I requested to export snip tool. But just to be clear - splitting into separate libraries is always good. But I strongly doubt that this will make it easier to maintain. Because even if it attracts contributors - developing a C library and maintaining it along with the Qt glue is much harder. If you think otherwise - feel free to take the code (it licensed under BSD) and start working on the library.
@Shatur Sorry being somewhat late to the party. Been working on LXQt's globalkeysd. Putting it short: From a developer's viewpoint its code is practically completely dead (takes weeks understanding its XEvent based state machine etc.). The (pretty much only) "up" side: Decent GUI confiiguration tool being widely accepted by users.
After finally winning some spare time I stumbled across libuiohook with evdev/libinput based implementation (with examples!). Now where's the point utilizing X if we can simply hook on the real deal and abstract it to this Qt "high-level" API?
I dare to say that (at least) under wayland this requires root privileges, because otherwise their security concept would be useless.
Because: "Please type password to access keyboard…" (never gets old) :rofl:
Not keyboard but hotkeys. But nvm. Found xdg portals. @Shatur do you know it?
Yes it does (got told so on irc).
https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.GlobalShortcuts
I don't know much about it, but to me it sounds like it is a higher level API to implement global Shortcuts and a lot of more other higher level Desktop Service apis. It's stems from Flat Pack but it looks really cool because it abstracts over the implementations of Shortcuts and other stuff, forced by Wayland to be handled by the compositors. furthermore in looks like in goes in the direction of apples security mechanisms.
https://flatpak.github.io/xdg-desktop-portal/
It is probably not an alround solution but it is still better to have it than not.
Since dbus is the only dependency a good solution in my opinion would be to check if the portals API is available and fallback to x11 mechanisms. but then check if the X11 connection is available at all before to avoid segfaults.
This way on platforms with a modern API portals can be used but still respecting non session-managed desktop environments like i3 or open box. As far as I know the gnome kde elementary support it yet.
@Shatur is see that you are not keen on doing this alone. Do you mint to open an Organisation, e.g. Q Community and move QHotkey there? We could agglomerate cool projects there like e.g. Qxt did back then (unfortunately practically dead)
The obvious thing I want to avoid
Naming the org somewhat like this comes with the implication that there is no particular person responsible to do the work.
It's not mine project, I can't move it. I just helping to maintain it a little bit.
I would be fine with transferring ownership of this project, if that is something you would agree to as well, @Shatur. Just mention me when you are ready and I will perform the transfer.
Yep, I don't mind. But I would wait for other similar projects to join first.