-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Description
Currently, the documentation for egui::Key reads:
Many keys are omitted because they are not always physical keys (depending on keyboard language), e.g.
;and§, and are therefore unsuitable as keyboard shortcuts if you want your app to be portable.
I think this is an unfortunate restriction for the case of wanting to develop an app for a limited audience with a known keyboard. I want to be able to assign features to e.g. the / key on my North American keyboard layout to focus to a search bar. I'm unable to, it seems to be implied, because not all keyboard layouts have a slash key. I really appreciate placing portability first but I think the available keys on my actual keyboard should at least come second.
To this end, would it be acceptable to have an API to detect whether any key is physically present? Non-portable keys could be found and queried this way, but non-portable keys should also be included in e.g. the events field of egui::RawInput so that they can be acted on in the same way as existing keys. Appropriate naming and requiring at least some extra typing on the programmer's part would make them think about why they're using non-portable keys and what it means for their audience.
If this approach sounds reasonable, I could try and put in some time to prototype these changes.
Related: #3266
Thanks by the way for this wonderful project! I've really been enjoying it