-
Notifications
You must be signed in to change notification settings - Fork 164
Add support for international layouts #53
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
Conversation
The Keyboard.begin() method now accepts a keyboard layout as an optional argument, which defaults to KeyboardLayout_en_US. The layout data has been moved to a separate file. Right now, en_US is the only available layout, but extra layouts can be defined by adding the appropriate definition files and declaring them in Keyboard.h.
This layout lacks the characters: - '`' and '~', which are not part of the standard Italian layout - '{' and '}', which require AltGr+Shift (not supported)
This layout lacks the characters '^' and '`', as they require pressing Space after a dead key, which is not supported.
This layout lacks the characters '^', '`' and '~', as they require pressing Space after a dead key, which is not supported.
Memory usage change @ ac0291b
Click for full report table
Click for full report CSV
|
Please note that the checks that failed did not fail because of the changes introduced by this pull request (they also fail on master). They fail because the CI pipeline attempts to compile the examples for platforms that do not provide the HID.h header file. |
LOVE THIS PR 😍 |
This obviates the need to test in press() whether it has been initialized, saving a few cycles and a few bytes of flash.
Has the review of this PR started? I just realized that setting _asciimap = KeyboardLayout_en_US; in the constructor obviates the need to test within |
Please, add it to this PR 🙂 |
OK, done. |
Memory usage change @ c609d4a
Click for full report table
Click for full report CSV
|
This pull request adds support for multiple keyboard layouts. Five layouts are initially included: US, French, Italian, German and Spanish. It is expected that users contribute additional layouts (I can add a few if requested). Adding a layout is straightforward by following the instructions in KeyboardLayout.h. It only requires one file defining it, and one line added to Keyboard.h.
Context
Arduino was born in Italy and has become very popular all over the world. The USA is only one among many countries that show interest in Arduino, and yet, the official Arduino Keyboard library supports exclusively the US keyboard layout. This has caused much confusion (#7, #20, #23, #24) and user requests (#8, #21, #25, #50, #52).
In the past, requests to support international layouts have been rejected with two arguments:
Regarding point 2, it should be noted that:
This pull request addresses this need while keeping the code simple and small.
API change
The only change to the public API is that the
begin()
method now accepts an optional parameter specifying the requested keyboard layout, e.g.As an optional parameter, it defaults to
KeyboardLayout_en_US
, thus preserving compatibility with existing sketches.Even though calling
begin()
is mandatory according to the official documentation, this method has been a noop until now. In order to avoid breaking existing sketches that fail tobegin()
, thepress()
method now callsbegin()
if it hasn't been called before.Resource usage
For a sketch using the default layout, the cost of this change is 100 bytes of flash and 2 bytes of RAM, as measured on an Arduino Micro. This doesn't change as the number of supported layouts increases.
Using a layout other than the default costs an extra 128 bytes of flash. This is because the default layout is always loaded in order to handle the case where the user forgets to
begin()
before using the library. It could be discussed whether supporting sketches that fail tobegin()
is worth the cost.Limitations
Keeping this library simple and small is a must. Because of this, this feature comes with some limitations:
^
on some layouts) are not supported for the same reason. They also break the simple assumption thatwrite(character)
equalspress(character)
followed byrelease(character)
.