Contribution related discussions

[materemias]

I think it makes sense to have a dedicated conversation about development and contributions to Voxtype.

[materemias]

@peteonrails you excluded CLAUDE.md from git, generally it makes sense to have it as part of the repo, can you explain / add it?

[peteonrails]

@materemias Sure - the Claude.md that I use mostly documents the build steps, validation, and docker container names that I use to make the binaries. I don't want to publish the details of my internal network and container deployments, so I need to do some work to split out the local stuff into a file that I can exclude before publishing the more generalized Claude configuration that understands the architecture, strategy and roadmap.

I do plan to do this work, but it has so far taken a back seat to bugfixing and feature-completeness.

[materemias]

if that means extra work for you skip that, we can all generate our own instructions.

[peteonrails]

I'm definitely not opposed to it. I think it will help some potential contributors who have submitted stuff that doesn't really fit the architecture and that needs rework.

[peteonrails]

I got it started here: #91 and merged this much. Happy to accept your improvements!

[peteonrails]

@materemias Also - I added you as a collaborator so that you can open PRs here without needing to fork, and so that you can claim issues and PRs for review. I made an assumption that you would want this, but feel free to let me know if you're not up for that.

[materemias]

@materemias Also - I added you as a collaborator so that you can open PRs here without needing to fork, and so that you can claim issues and PRs for review. I made an assumption that you would want this, but feel free to let me know if you're not up for that.

Thanks for that! I have never worked with Rust before, but will do my best 😎

[materemias]

I got the time to think about the modifier feature: my original idea was to have different languages assigned to different hotkeys, eg

• SCROLLLOCK: auto
• RSHIFT+SCROLLLOCK: en
• RCTRL+SCROLLLOCK: hu

this can be idea A) which has a bit of conflict with the hotkey-modifiers section.

a more generic approach could be to have the modifier override any part of the config which could lead to such situation:

• SCROLLLOCK: language = auto, model = large-v3-turbo
• RSHIFT+SCROLLLOCK: model = base.en, mode = clipboard
  ... etc

in both cases hotkey-modifiers should be dropped or rethought
what do you think?

[peteonrails]

I agree with the thinking for a more generalized approach. I have seen some folks using Hyprland compositor bindings to achieve similar results using keybindings (mostly for output-mode=paste vs output-mode=type).

In retrospect, I think that since I was targeting Wayland from the start, I should never have done native keybinding with evdev, instead using the compositor-native approach. But since I started out by supporting X11 and native keybinding support via evdev and ydotool, it's probably something to keep for compatibility.

I'll see about collecting some data on whether folks are using native hotkeys or composite key bindings, and that might help us think about how careful to be when changing that functionality.