development focus for future features

[nnako]

Hi,

first of all: AMAZING work you did!!!

I just stumbled across your project, today. And as I myself started writing a very much related application, a couple of years ago, I was wondering if there were possibilities of joining forces for higher goals ;-) .

My goal is to provide an application which runs in the Windows OS'es background (like yours) and listens for key presses (mouse clicking would not be highest priority). The main goal of the application would be to provide the following features to its users:

• switch between applications (could even be done using Window's native keys like <ALT> + <TAB>, ...)
• on each change-of-application, an application-specific set of hotkey configurations gets activated. hotkey configurations translate the user's key presses into application-specific key-press-sequences necessary to realize a specific functionality.
• so, this application-specific sets of hotkey configurations provide translation between user-desired key sequences and their application-specific realizations (e.g. using the sequence :w to save a document in MS WORD. So, translated into <CTRL> + <S> when MS WORD is active window)
• the application should provide different "operation modes" to be used / configured for any applications. Using these modes, a mechanism as realized in the VIM editor could be implemented. Thus, being able to even provide hotkeys for each "mode" an application was currently in. VIM uses "normal" mode e.g. to navigate within a given text, "insert" mode to actually add / remove characters, "command" mode to issue all kinds of commands / functions, ...
• the application should provide different kinds of low-level-input-schemes. E.g.
  • normal text, where each key press results in a character within the selected application's editor window
  • abbreviations, where a pre-defined (short) sequence of text triggers a whole text block to be inserted
  • commands, where a leading ":" opens a dedicated command line to insert specific commands
  • ...

For all this, I need a "crisp" and reliable keyboard interface on the lowest layer:

• 100% stable keyboard interface, see stability of low-level keyboard interface #4

• 100% stateless operation
  Even when pressing the weirdest key combinations in any humanly possible sequence and typing speed, I would want to have a clear and clean status whenever I switch from one application to the next one. No hanging control keys, no hidden state influencing the current key sequences for the current application. Hanging control keys I have encountered in Python's keyboard module. Which disqualifies the usage of that great library for the intended purpose.

• 100% stable switching between applications, see when switching between applications, key presses bleed #5

[klesh]

Hi, @nnako Thanks for your interest, I'm thrilled to join forces with you.
I read your idea and it seemed like some application-aware automation to me, it is not supported at this point but totally possible from what I can tell, actually, It is in my mind as well. I haven't got to it yet because I have other priorities:

1. The low-level keyboard interface is not stable enough, like you mention in stability of low-level keyboard interface #4 , and I noticed that not all applications play nice with the Synthesized events. For example, the Emoji Input (activated by Win+.) doesn't take it well.
2. It should not be a problem.
3. I would like to investigate this case since the keys would be swallowed and show not be bleeding.

[nnako]

Hi @klesh . Great news.

I've superficially looked into your code base and would like to help integrate anything I had so far into it. Looks very structured to me. Worth using as a base. Unfortunately, I am not so strong concerning the implementation of native connections to the underlying operating system (handling interrupts, events, ... especially on Windows), yet. So, I would be happy if you could point me to valuable sources of information or provide some more structural diagrams of your own code (like how the different modules are related to each other, what happens where, ...). All would help me to faster get on track within your code.

Would this be a possibility? What do you think?

[klesh]

@nnako Yes, it is possible, but I don't have any diagrams at this point. I could try to draw some when I have time.
Maybe I could give you a brief based on what you are trying to do.

1. jmk is handling the keyboard and mouse event, the main idea is to intercept the Low-Level Input Events from the OS, and produce a set of new Input Events to the OS or call given python function. it is designed as a set of state machines:
   • sysinout.py connects features to the OS, so that we can write unit tests for any state machine if we need to
   • core.py implements functionality like Layers/HoldTap just like the QMK and ZMK
   • hotkey.py implements traditional Modifiers-based hotkey.
2. w32 wraps all needed win32 APIs into Python functions, so it will be helpful if you need to know what Application is currently activated.

Based on my understanding of your objective. I suggest that we should add a new state machine into the jmk module that can remember what has been entered for an app and trigger the given function accordingly. jmk.seq sth like that.