[feat] Add a proper awesomely flexible and powerful trigger key system

[eugenesvk]

It's rather important for such a frequently used app to have an extra convenient key trigger
Alt+Space isn't that - requires two hands or and inconvenient two-finger movement

But better alternatives are currently blocked by the way the app handles keybinds, it can only handle simplistic keybinds, what would be better if you could map the following as triggers:

• Capslock (single finger, replaces a useless key, though it's a pinky)
• RightCommand single short tap: excellent location, most convenient right thumb single finger, also short tap prevents conflicts with Cmd+X keybinds and also if you pressed Cmd thinking of a keybind but then changed your mind and released (it's a long tap, not a short one, duration should be configurable)
• LeftCommand double tap: similar idea, but different way of avoiding conflicts
• (hold)Space+F: two fingers, but it's thumb+home row prime location
• (hold)F+D: two fingers, but again this is prime home row location

Currently the way to achieve this is to use a proper keyboard remapping tool like karabiner on a Mac and then bind the actions to some bland inner app keybind, but it would be awesome if at least one launcher utility were remotely as powerful on its own

And the best part that is almost impossible to replicate with an external rebinding tool (since it depends on app's internal context) is you could then use the same system everywhere. For example, if you have a list of resulting apps and want to add App#5 as a favorite, you could map "hold(space)+F" to add to favorites

[unsecretised]

Hmm... this is a good suggestion... Not sure how to implement this though, since the library we are using currently (global-hotkey) requires a key and a modifier is optional.

[eugenesvk]

To track input:

• On a Mac that's done via event observation, here is an overview from Karabiner Elements dev https://docs.google.com/presentation/d/1nEaiPUduh1vjks0rDVRTcJaEULbSWWh1tVdG2HF_XSU/edit?slide=id.p#slide=id.p
  (some of the more powerfule methods unfortunately require registering the app as an accessibility provider)

• On Windows you'd similarly add an inputhook to check when the required combo is pressed

Then on how to process it not sure, but there is this awesome Kanata Rust keyboard rebinding app (it's as poweful as QMK, so it supports home row mods and differentiating tap vs hold ), maybe you could extract the keyboard layout remapping/processing part and use that and share internal app state changes as signals to change keybiding layers (in a standalone app it supports getting external messages via TCP protocols, so that would be similar, but without the extra protocols)

Then users could use the existing kanata config language to define various ergonomic actions themselves or just toggle pre-defined rustcast examples

(kanata has input handling on Mac via Karabiner, but on Windows it adds inputhook, so that could be used as well. Though maybe on a Mac if Karabiner is isnstalled with its driver, maybe rustcast could also use that? not sure exactly how kanata is doing that on a Mac)

[Mnem42]

Yeah, that's what I was thinking of for windows, idk how other platforms do things

[unsecretised]

Could potentially use rdev for this

[unsecretised]

So I took a look into this.. when I tried using code like this:

pub fn global_handler(shortcut: Shortcut, sender: ExtSender) {
    let mask = NSEventMask::KeyDown;

    let shortcut_clone = shortcut.clone();
    let sender_clone = sender.clone();

    // Interior mutability so we can call `send(&mut self, ...)` from an `Fn` block.
    let sender = Rc::new(RefCell::new(sender.0.clone()));

    let block = RcBlock::new({
        let sender = sender.clone();
        move |mut event: std::ptr::NonNull<NSEvent>| {
            let event = unsafe { event.as_mut() };

            let key_code = event.keyCode();
            let mods = event.modifierFlags()
                & (NSEventModifierFlags::Command
                    | NSEventModifierFlags::Option
                    | NSEventModifierFlags::Control
                    | NSEventModifierFlags::Shift);

            if key_code == shortcut.key_code && mods == NSEventModifierFlags(shortcut.mods) {
                let mut s = sender.borrow_mut();
                let _ = iced::futures::executor::block_on(s.send(Message::KeyPressed(0)));
            }
        }
    });

    NSEvent::addGlobalMonitorForEventsMatchingMask_handler(mask, &block);
}

RustCast launch times decreased.. and while I know it would be nice to do this, i think requiring someone to use Karabiner to do this would be ideal over the messy code, which also requires a custom implementation of parsing the config to the hotkey struct..

Mainly i would say that using karabiner or a few simple hidutil commands via the CLI should be enough.. but in the future or for hyperkey, it might be a good idea to do this..

[eugenesvk]

Mainly i would say that using karabiner or a few simple hidutil commands via the CLI should be enough..

It wouldn't since it's

impossible to replicate with an external rebinding tool (since it depends on app's internal context)

To make that viable you'd need to expose a way to communicate/export app context via some IPC and also expose rustcast custom commands as input via the same IPC. Then you could have some extension at the level of the keybinding tool that could drive rustcast depending on its context

[unsecretised]

Hmm... i missed that part.. but if thats the case, then it should probably be implemented

However, I can't seem to make this work in a way thats fast enough in comparison to the speed its at now.

if you or someone else is willing to take on this challenge then do go ahead! I'd be open to taking a look into your implementation, and help out with what i know (although its fairly less)