Skip to content

Commit a394aa0

Browse files
committed
add alpha note to readme
1 parent 78c27b3 commit a394aa0

File tree

1 file changed

+8
-2
lines changed

1 file changed

+8
-2
lines changed

README.md

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -33,10 +33,16 @@ listenkey.exe and sendkey.exe are standalone applications. Run `listenkey -h` an
3333

3434
See `layout1.py` and `layout2.py` for examples of how to write and run a processor.
3535

36-
## Warning
36+
## Warnings
37+
38+
### Use with care
3739

3840
listenkey.exe with the -c option will prevent key events from reaching the applications. Unless you use it in combination with the -e or -d option, you run the risk of partly losing control of your computer. This particular foot gun is necessary for the core functionality, so it will stay this way. The recommended and conservative use is to always have the -e option turned on. This way, if your processor hits a snag you can always press Esc to exit listenkey.exe. In order to make use of this option, you will need a layout that doesn't require using the Esc key.
3941

40-
## Known bugs
42+
### Known bugs
4143

4244
For security reasons, Windows does not allow all key event to be scoped up by an application like keyboa is attempting to do. Sometimes, a key down event can be sent to keyboa while the key up event is withheld. This can for example happen when Win+L is pressed to lock the desktop, or when switching to an application running with elevated privileges. From the perspective of your processor, this will look like a key being held down indefinitely. There is library functionality that attempts to compensate for this situation (unstick_keys), but it is not perfect.
45+
46+
### Alpha stage code
47+
48+
This code is in alpha stage, and the API will not be stable before release of version 2.0.0.

0 commit comments

Comments
 (0)