Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow enabling Plover on a subset of keyboards #1187

Open
user202729 opened this issue Feb 26, 2021 · 8 comments
Open

Allow enabling Plover on a subset of keyboards #1187

user202729 opened this issue Feb 26, 2021 · 8 comments

Comments

@user202729
Copy link
Member

user202729 commented Feb 26, 2021

(as explained in the title.)

Sometimes the user might want to use a mechanical keyboard to type in steno and the normal keyboard to type in Qwerty. It should not be necessary to PHROLG every time.

Extension: allowing multiple keyboards to be able to type in different steno systems.

Another extension: recognizing input from multiple types of machines at once.
(perhaps this is not very useful, same way as how people only type from one keyboard at a time; besides, perhaps keyboard+professional steno machine is the most common option)

@benoit-pierre
Copy link
Member

Possible on Linux (the code pretty much already support it: you can try changing XINPUT_DEVICE_ID in plover/oslayer/xkeyboardcontrol.py). From what I remember, hard to impossible on Windows (standard API don't allow differentiating devices). No idea about macOS.

@benoit-pierre benoit-pierre changed the title (Feature request) Allow enabling Plover on a subset of keyboards Allow enabling Plover on a subset of keyboards Apr 2, 2021
@user202729
Copy link
Member Author

user202729 commented Apr 11, 2021

It might be possible on Windows:

https://www.codeproject.com/articles/716591/combining-raw-input-and-keyboard-hook-to-selective

Perhaps ctypes can also be used here, like how it was used for the hook API.

Root (administrator) privilege appears to be unnecessary, unless the driver method is used.


Related: https://github.com/boppreh/keyboard/issues/21#issuecomment-320483942 (avoid GitHub issue linking) -- for unknown reasons, that comment claims that the hook event comes after the device id so blocking is harder; while the article above claims that the hook is before -- see also the last comment.


This feature can be implemented in a separate (machine) plugin as well, although there might be significant code duplication with Plover's keyboard/oslayer module.

@user202729
Copy link
Member Author

user202729 commented May 13, 2022

Testing around a bit macOS can
CGEventGetIntegerValueField(event, kCGKeyboardEventKeyboardType) to distinguish different keyboards...
on another read, it merely distinguish between different keyboard layouts (40: ANSI, 88: macOS layout, etc.?)

https://github.com/Hammerspoon/hammerspoon/issues/2643 (no crosslink) contains some more information.

It links to a C program that shows how to suppress all keys in internal keyboard, but that requires IOKit.

Unfortunately, IOKit will not be wrapped in pyobjc... although it looks like there are different libraries.

@user202729
Copy link
Member Author

With all the pending reorganization on oslayer, it would be somewhat hard to get this implemented...

@user202729
Copy link
Member Author

user202729 commented Sep 10, 2022

Thinking about it, if this is enabled it would also make sense to set the keyboard error to "disconnected" when none of the keyboards in the subset can be found.

It would be better to disable plover-auto-reconnect-machine plugin with this feature though (because the plugin is hardcoded to check serial port only)

I implemented the feature in my test dev branch, seems to work well. Only for X though since that's the one I need the most.

(also because my keyboard connection is a bit fickle, so seeing whether it's connected is very useful)

@user202729
Copy link
Member Author

user202729 commented Jan 24, 2024

My original plan is to develop something like this:

image

But I realize it is overkill, because it is highly unlikely that the user would want to use more than one keyboard anyway.

There's just one case where it makes sense to enable on all keyboards: when the user uses the default configuration (and there are multiple keyboards connected). Then, we wouldn't know which keyboard the user want to use.


In retrospect, it would also makes sense to allow setting arpeggiate per keyboard. But implementing all the logic correctly is going to be difficult.
(essentially we want to run multiple machines in parallel, each one collecting key presses and send strokes independently. But if someone needs that feature, it would be beneficial to listen for multiple machines at the same time as well...)

@aerickt
Copy link

aerickt commented Jan 24, 2024

I'm actually running into this issue. I use a Multisteno with Plover as my main keyboard, but I'm also currently trying to learn controller steno. Having to switch the protocol between Gemini PR and Controller is really cumbersome and annoying.

@user202729
Copy link
Member Author

This is not exactly what this issue addresses (although it is addressed in the extension "Allow from multiple inputs"). If the protocol is different, you can simply use a translation with the format

{plover:set_config:'machine_type':'Gemini PR'}

to switch between them.

Of course, there's also a small problem is if you want to switch from Controller to Gemini PR then you need to press the chord on the controller.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants