~eliasnaur/gio#319: 
key: providing key symbols

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?

Status
REPORTED
Submitter
~changkun
Assigned to
No-one
Submitted
1 year, 2 days ago
Updated
2 months ago
Labels
No labels applied.

~eliasnaur 1 year, 1 day ago

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.

~changkun 1 year, 1 day ago

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

~eliasnaur 1 year, 1 day ago

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.

~changkun 7 months ago*

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

~eliasnaur 7 months ago

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.

~dennwc 2 months ago

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 the Set filter. For platforms that cannot fill the name, it can fallback to something like android.C12345 (where C stands for "code").

~eliasnaur 2 months ago

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?

~dennwc 2 months ago

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.

~eliasnaur 2 months ago

Why not just fill in reasonable Names and let a future change align the other platforms?

~dennwc 2 months ago

OK, platform-specific names it is.

https://github.com/gioui/gio/pull/102

Register here or Log in to comment, or comment via email.