search

VollRahm / NotEnoughHotkeys

This is an Application to block input from a secondary keyboard and instead run custom defined Macros
MIT License
50 stars 4 forks source link

[IDEA] Separate GUI for managing macros from the run time service that locks the keys and runs the macros into two executables #20

Open donpark2000 opened 2 years ago

donpark2000 commented 2 years ago

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Elevation of Process: Was it running as Administrator?

Additional context Add any other context about the problem here.

donpark2000 commented 2 years ago

This Github interface is not intuitive. I just wanted to leave a few ideas. I hope you get this.

I like the functionality. My suggestions are: 1) Separate the GUI Macro Creator from the runtime component so the run time can be started as a background service, decoupled from macro creation. 2) Add the concept of layers so the same keyboard can trigger multiple suites of macros for a given keyboard (for example, application specific macros). At the backend, it seems to be as simple as switching between various json files that define separate "layers". 3) If you do the layer thing, it would be nice to have a simple interface to switch layers. For example, make layer switching a hotkey function itself. 4) The GUI macro creator is a nice way to get started, but tedious for setting up multiple hotkeys. What I have in mind is a single Autohotkey script invoked by your software with a different argument depending on the key pressed. To that end, copy/paste might make it easier (and then just edit the parameters to say what key binding sends which argument to the AHK script).