Hi, I wonder how to access the raw platform key symbols quickly.
So far, the key events are described in key.Event, they are represented in a combination of the triggered modifier as well as the name of a key as a string. Yet seems not easy to convert the key symbol of, for instance, a delete key.
Moreover, it is also not entirely clear (from documentation) how to trigger modifier key events individually. Say if a control key is pressed, we will not receive a key.Event from Events() unless we press a non-modifier key.
Any ideas on how to overcome this shortcoming beyond creating a self-maintaining key mapping table?
So far, the key events are described in key.Event, they are represented in a combination of the triggered modifier as well as the name of a key as a string. Yet seems not easy to convert the key symbol of, for instance, a delete key.
Special keys have name constants in the key package. For example, the delete key to map to key,NameDeleteForward (regardless of the shift modifier).
Can you elaborate what exactly you need? Perhaps renaming Name to ShiftedName and let Name contain the unmodified name?
Moreover, it is also not entirely clear (from documentation) how to trigger modifier key events individually. Say if a control key is pressed, we will not receive a key.Event from Events() unless we press a non-modifier key.
Adding names for modifiers and reporting key.Events for them sounds good to me.
Any ideas on how to overcome this shortcoming beyond creating a self-maintaining key mapping table?
Still not quite sure what your exact needs are. Please elaborate.
Thanks for the response. Sure, that sounds like a nicer solution. Name may use Symbol, KeyCode, or others that is typed as an integer.
More specifically, for examples:
https://git.sr.ht/~eliasnaur/gio/tree/main/item/app/os_macos.go#L341 https://git.sr.ht/~eliasnaur/gio/tree/main/item/app/os_windows.go#L216 https://git.sr.ht/~eliasnaur/gio/tree/main/item/app/os_x11.go#L502
The original key code provided by the system is converted internally through functions like convertKey, DispatchKey, etc. This seems not possible to reverse this process from the userland. Especially when the keyboard is not in US layout.
The reason I am concerning the need for original key code was that I am writing a program to communicate via a so-called guacamole protocol[1] where the original key code must be provided hence requiring reversing from Name string to Keycode integer.
[1] https://guacamole.apache.org/doc/gug/protocol-reference.html#key-instruction
Thank you for the guacamole use-case. I agree that adding a KeyCode integer field to key.Event sounds like a reasonable addition. It should be clearly marked as non-portable and that users should prefer Name if at all possible.
Hi, sorry for pushing this...
Is there any progress on this? I would to love to make some progress on a pending Gio application that is blocked by this ticket: https://github.com/changkun/occamy/pull/51
I don't think anybody is working on this. I encourage you to attempt at least a proof of concept yourself. I believe it's a two-step process: (1) adding a KeyCode field to key.Event (2) change the platform implementations to fill the field. If you start by adding support for the platform(s) you're most comfortable with, I'm sure the community can help with the rest.
See https://gioui.org/doc/contribute for details, especially the GitHub mirror if you're not comfortable with patch emails.
I'm interested in adding support for this as well, and I started experimenting with it already.
There's one question to consider: should the platform attempt to fill the
Name
field?It can be namespaced, e.g.
android.X
, in which case it will also be possible to list those keys in theSet
filter. For platforms that cannot fill the name, it can fallback to something likeandroid.C12345
(where C stands for "code").
Good question. It would be unfortunate to have platform-specific Names. Can you name examples of keys that don't have a natural name, or that is strictly platform-specific?
I don't have any examples like this. Currently I'm experimenting with Gio on Android TV and wanted to map the colored keys on the remote, for example. But I guess these keys will still have similar names if a pure Linux distro is installed on the same hardware.
However, aligning all key names to a single definition for all platforms sounds too complicated for the first version. The namespaces approach I mentioned allows to start using keys in
InpuOp
filters without requiring a 100% alignment on all platforms. Downside is that once we start aligning these keys, the filter will break.So it's up to you. I can keep the names empty and only add the code for now.
Why not just fill in reasonable
Name
s and let a future change align the other platforms?
OK, platform-specific names it is.