Mainly some refactoring with the command-handling in lefthk-core.

Benefit

Whenever you want to create a new command, this just needs to be done: config/command/<new command>.rs

// register the new command
inventory::submit!{DenormalizeCommandFunction::new::<MyNewCommand>()};

pub struct MyNewCommand {
    // the arguments of the command
}

impl Command for MyNewCommand {
    // ...
}

done!

TL;DR

I propose to write every command as a struct instead of putting all commands into an enum. What do you think about @AethanFoot

Motivation

A command has a lot of properties in my opinion. This includes: - matching a string to themself - converting themself to a string - do that what their name says (like reload the daemon if the Reload Command was called) - having different arguments

those are all I could find yet and in my opinion this is why we should split the commands up from an enum into a struct for each command.

How should it look like

Example: config/command/mod.rs

mod chord;
mod execute;
mod exit_chord;
mod kill;
mod reload;

use std::convert::TryFrom;
use crate::errors::LeftError;

pub use self::{chord::Chord, execute::Execute, exit_chord::ExitChord, reload::Reload};

pub trait Command<'a>: ToString + Default + TryFrom<&'a str> {}

config/command/chord.rs

use crate::config::Keybind;

use super::Command;

#[derive(Debug, PartialEq)]
pub struct Chord(Vec<Keybind>);

impl Chord {
    pub fn new(keybinds: Vec<Keybind>) -> Self {
        Self(keybinds)
    }
}

impl<'a> Command<'a> for Chord {
    // bla bla
}

// other functions which are *only* relevant to `Chord`

Pros and Cons

Pros

• logic of each command is only isolated in a file, while an enum gets bigger and bigger and the the enum includes the whole logic of all enum-entries

yeah, that's basically it. All functions which affect to all commands (like searching through them) can be put to config/command/mod.rs, the "main" command file.

Cons

• the syntax might be a little bit strange for the beginning like here. This should be, in my opinion:

fn main() {
    // ...
    send_command(command::Kill::boxed());
    // ...
}

fn send_command(command: Box<dyn Command>) {
    let path = errors::exit_on_error!(BaseDirectories::with_prefix(lefthk_core::LEFTHK_DIR_NAME));
    let pipe_name = Pipe::pipe_name();
    let pipe_file = errors::exit_on_error!(path.place_runtime_file(pipe_name));
    let mut pipe = fs::OpenOptions::new().write(true).open(&pipe_file).unwrap();
  
    // difference is here with `command.to_string()`
    writeln!(pipe, "{}", command.to_string()).unwrap();
}

which would be more typesafety and also makes it easier to change the code since you don't have to replace the string "Kill" everywhere if you want to rename this command.

Add a keybind for exiting out of current chord. If a "global" one is set, it will be used for all child chords unless one is set for it specifically. This will occur recursively as chords can technically be nested infinitely :fearful:. Thanks.

I had trouble making the deamon react to a key press from XF86AudioPlay coming from a bluetooth headset, due to this keysym have multiple codes associated (had 172 by default and the headset sent a 208).

It seems the reason is the same as described here : https://github.com/electron/electron/issues/2210 , in short XKeyGrab is only used with code 172 thus code 208 aren't registered.

I manually added a XKeyGrab for the code 208 and it worked, but I haven't found a more elegant solution (not really familiar with Xlib). I have seen people use xbindkeys to detect key pressed event with this code and map it to send a XF86AudioPlay key pressed event with xdotool, maybe lefthk could also have some way to configure keys by code?

Create a new default modifier param and make keybind modifier optional, based on #9 Create test for the new parser of config

• [x] feature
• [x] tests

Note: after talking about this feature, I think this feature is necessary for future features.

Hey,

Thank you so much for you work! I just wanted to test out new eco-system tool cause I really like "modes" of keybindings. But when I start daemon by some reason it works approx. 2 times of 5. I made a small look into code and realized that most probably it happens somewhere here when it is trying to get mutable reference of listener(???).

Could you please help with this issue?

This could be used to implement some keybind infos in bars or widgets. Especially when entering a chord it might be useful to have visual feedback and info about the available key commands.

Eventually it would be nice to have a interactive mode (maybe with a little tui?) to create new keybinds. This should be especially be helpful for binding obscure keys, or with use of odd keyboad layouts.