init attempt at new kb

[cjpais]

This PR gives people a choice for the keyboard backend.

The default on Windows and MacOS is now the "Handy Keys" backend. This is a ground up implementation and hopefully should fix a lot of bugs/outstanding issues in regards to how the frontend captures keyboard shortcuts and how the backend can globally listen for them

The big changes from a user perspective are:

• The global shortcut can be just modifiers (ctrl+shift) for example.

On MacOS this also means that you can

• Use the fn key as a global shortcut

From a developer perspective, one thing that has changed is that the new keyboard back end will forward the key events to the frontend so that they're always in sync with each other. There were a bunch of issues where there was some synchronization between the two that was just messy and error prone. In the future, we'd like to move to the Handykeys back end entirely. But for now, we're going to to leave it in a testing state, but we need really solid testing from users to make sure it's good.

[github-actions]

🧪 Test Build Ready

Build artifacts for PR #580 are available for testing.

Download artifacts from workflow run

Artifacts expire after 30 days.

[cjpais]

Calling all testers. Could you give the build a run on your system? I need help validating that global shortcuts still work as expected, and that you can change the shortcut in the app itself. The default global shortcut library has changed on MacOS and Windows. For Linux testers, please go into the debug menu (ctrl+shift+d) and change the "Keyboard Implementation" to "Handy Keys" instead of "Tauri Global Shortcut"

What needs testing:

• Ensure your keyboard shortcut still works
• Ensure you can change your keyboard shortcut and that works
• Try only modifier keys (ctrl+shift) or something like this and ensure they work
• (macOS only) try the fn key as a modifier

Windows 10:

@schmurtzm
@bustozoni

Windows 11:

@giuliofoletto
@bustozoni
@BerthalonLucas
@jstone09
@cassionevezzz
@Katalizatori

Windows ARM:
@lightsabata

Linux:

@BerthalonLucas
@bustozoni
@tanshkoul
@MikeTheGreat

MacOS:

@mawnir - intel

[lightsabata]

hi
6.11 Windows 25H2 (ARM)
default shortcut working (ctrl + space, never change previously)
custom shortcut working (shift + space)

Always working like a charm

[hbenthow]

For me, it has the same behavior as before. I can still use the Insert key as my custom shortcut as I have been doing for months now, but when I try to use ScrollLock instead it gives me an error. However, previously it never explained why there was an error, whereas this time it gave me an error message which I have included in this picture.

[hbenthow]

For me, it has the same behavior as before. I can still use the Insert key as my custom shortcut as I have been doing for months now, but when I try to use Scroll Lock instead it still fails. However, previously it never explained why there was an error, whereas this time it gave me an error message which I have included in this picture.

[DavidGP]

Strangely for me, it doesn't seem to accept any shortcuts anymore, not even the normal ones containing a modifier key.

[gordinmitya]

macbook air M4, macos 26.2 (25C56)
Tested new backend with alt+space, fn, shift keys - everything works fine. Switched back to tauri backend - resets shortcut to default and works.
Long-awaited feature!

[cjpais]

Thank you @DavidGP, I was suspicious it would just work out of the box on Windows as that backend is fully untested code. Are you able to collect a log by chance? Curious to see if there is anything there

@hbenthow to be fair I dont think I included scroll lock in the library, let me see if I can, however im not convinced it will capture. do other keys/modifiers work for you?

[DavidGP]

Are you able to collect a log by chance? Curious to see if there is anything there

Thank you @cjpais

I've tried to enable debug mode like this in the settings file:

    "debug_mode": true,
    "log_level": "debug",

...but can't seem to find a debug log anywhere. Is there something else I can do?

[cjpais]

ctrl/cmd+shift+d in the debug menu should show you where the logs get put

[eiffel31]

While I can run the AppImage from the 0.6.11 release assets, I am not able to run the AppImage from these artifacts (Linux Debian 13).
The error message is:
dlopen(): error loading libfuse.so.2
AppImages require FUSE to run.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information

[mawnir]

1. Ensure your keyboard shortcut still works: works fine
2. Ensure you can change your keyboard shortcut and that works: no problem
3. Try only modifier keys (ctrl+shift) or something like this and ensure they work: yes ctrl+shift work
4. (macOS only) try the fn key as a modifier: not working
   i have intel mac

[hbenthow]

do other keys/modifiers work for you?

Yes. As I mentioned, I've been using Insert for months now.

[eiffel31]

On Linux Debian 13, Wayland:

[2026-01-17][11:16:57][handy_app_lib::shortcut][INFO] Switching keyboard implementation from Tauri to HandyKeys
[2026-01-17][11:16:58][handy_app_lib::shortcut_handy][INFO] handy-keys manager thread started
[2026-01-17][11:16:58][handy_app_lib::shortcut_handy][INFO] handy-keys shortcuts initialized
rdev grab error: IoError(Os { code: 13, kind: PermissionDenied, message: "Permission non accordée" })

Note: I extracted the AppImage to launch the AppRun, this solves the fuse v2 problem referred above.

[cjpais]

@mawnir to confirm, did you check you are using the handy-keys implementation in the debug menu

@eiffel31 thank you for the log. for the main release app image do you have the same issue?

[github-actions]

🧪 Test Build Ready

Build artifacts for PR #580 are available for testing.

Download artifacts from workflow run

Artifacts expire after 30 days.

[cjpais]

@hbenthow can you try this latest build it may or may not work, but there are some changes which ideally should help

[eiffel31]

@eiffel31 thank you for the log. for the main release app image do you have the same issue?

@cjpais
The main release AppImage is working fine.
Note: When the mentioned error appears, there are 2 solutions;

• Extract the files from the AppImage en run AppRun file
• Install package libfuse2t64

[cjpais]

@eiffel31, mainly wondering if this build helps resolve from #305 when using the new Handy Keys backend

@mawnir, if you scroll down there's a new option

[cjpais]

@Ragnar-D5 did you try the "Handy Keys" implementation which is in the debug menu? Just want to confirm that backend is being used. It should allow for just modifiers. If you are not using it (which on linux the default is the existing implementation) then it will not allow modifiers

[Ragnar-D5]

@Ragnar-D5 did you try the "Handy Keys" implementation which is in the debug menu? Just want to confirm that backend is being used. It should allow for just modifiers. If you are not using it (which on linux the default is the existing implementation) then it will not allow modifiers

You are totally right, I didn't see that. Sadly I get the same error as eiffel in debian after activating the backend:

After activation my keystrokes are not being recognized by Handy. I can neither change the shortcut, nor activate it.

Now I didn't read for more than one Minute of the rdev documentation, but might this be the problem?

Linux

The grab function use the evdev library to intercept events, so they will work with both X11 and Wayland In order for this to work, the process running the listen or grab loop needs to either run as root (not recommended), or run as a user who's a member of the input group (recommended) Note: on some distros, the group name for evdev access is called plugdev, and on some systems, both groups can exist. When in doubt, add your user to both groups if they exist.

[cjpais]

@Ragnar-D5 yes, could you try and adding yourself to the groups and see what happens?

[Ragnar-D5]

Even after adding myself to both groups, I only get an additional error message and whenever the field for inputting the shortcut keys is activated, the whole system might freeze for several seconds.

Sometimes it is able to pick up the keys I press in the window, other times it is not

[eiffel31]

I just tested latest build above.

Here is the log:
[2026-01-19][06:58:44][handy_app_lib::shortcut][INFO] Switching keyboard implementation from Tauri to HandyKeys
[2026-01-19][06:58:44][handy_app_lib::shortcut::handy_keys][INFO] handy-keys manager thread started
[2026-01-19][06:58:44][handy_app_lib::shortcut::handy_keys][INFO] handy-keys shortcuts initialized
rdev grab error: IoError(Os { code: 13, kind: PermissionDenied, message: "Permission non accordée" })

Note:

• I am in input and plugdev groups.
• System is Debian 13, Wayland

[dudemeister23]

With this build, pressing F3 to bring up all windows on macOS instead attempts a transcription, even though it's set to the function key. The original function of that key to bring up all windows is not working.

If this has been brought up above I wasn't able to discern it.

[cjpais]

Wow this is a very good bug report @dudemeister23, I can replicate this as well. Will try and fix before release

[cjpais]

Okay anyone trying the new build, there is now a new UI. The selector for the keyboard implementation is now in the 'advanced' settings menu. There is a new toggle for 'experimental' features and it is under that toggle. It will enable a hidden set of features. Scroll down to the bottom of advanced and you should see the new features

[github-actions]

🧪 Test Build Ready

Build artifacts for PR #580 are available for testing.

Download artifacts from workflow run

Artifacts expire after 30 days.

[cjpais]

@dudemeister23 try the new build, it fixed it for me

[dudemeister23]

@cjpais Indeed, it is fixed now. That was some very fast work. Awesome. Thanks so much.

[cjpais]

@dudemeister23 I really want to get this PR released in the next day or two and cut 0.7.0! Even if it doesnt work for Linux/Windows yet (they will just use the old version), it will address a bunch of Mac requests!

[peterjaap]

@cjpais tested the AppImage on Ubuntu 24.04 and the push to talk now works!

Edit; oh wait, only when Handy is the active window. Not from other windows.

Edit 2; ah, when I enable Experimental settings and select Handy Keys under Keyboard Implementation, it does work! 🥳

[eiffel31]

On Debian 13, Wayland, Tauri Global Shortcut:

• shortcut selection consider QWERTY keyboard
• shortcut detection consider the keyboard layout
• shortcut detection requires the window to have focus

Handy Keys: unable to configure any shortcut, same error ( rdev grab error: IoError(Os { code: 13, kind: PermissionDenied, message: "Permission non accordée" }))

[mawnir]

@mawnir, if you scroll down there's a new option

Yes fn key work on intel mac(with handy keys).. great job

[cjpais]

Alright I think there's been enough feedback on this for MacOS to merge. Will get more feedback for Windows and Linux in prod

[STVGecko]

As a Windows 11 user, I installed Handy_0.6.11_x64_en-US and set up the "Handy Key" keyboard. However, none of the keys on the keyboard are functioning. Everything else is working.

[cjpais]

Thanks yes I think there is something broken in the Windows implementation. Hopefully I will be buying a windows laptop soon and able to test at least a little