Support multilayer keyboards

Request Feedback
1

Hi,
i use a keyboard layout that uses 6 Layers (Neo2).
On the commit (9600954d8de57442dfe1269dcf80e3d23edbaf0a) the behavior of key in KeyPressed event changed.
The key no longer uses any modifications, which means it uses the symbol from the base layer.
It is not good for shortcuts using symbols like ‘), (, ?’ that are on a layer 3, but it is especially surprising that the arrow key, backspace and other named keys from layer 4 are not working anymore.

The commit (94c8b9639ca2d287c504345390585b80dc0d78cf) introduced the modified_key that restores the original behavior but it is not used.

Is there a reason why the key in the KeyPressed event should be the baselayer key?

As path forward i identified three ways.

  1. make the key in KeyPressed be the modified key and add a special entry for the baselayer for those who need it. (proposal)[modified_key as default key · Gerd-Augsburg/iced@448fc41 · GitHub]
  2. Promote usage of modified_key and use it in widgets and examples. (proposal)[prefer modified_key to support multilayer keyboards · Gerd-Augsburg/iced@864e15a · GitHub]
  3. In search of named Keys try key and modified_key, than at least basic navigation would work.

Path 1 has the least change and i would prefer it, because the Apps downstream are using key and convincing every app that i want to use to change to modified_key is cumbersome.

Are there other Problems to consider?

2

What field are you reading from KeyPressed? Because the final or “modified” text is still available in KeyPressed.text: Event in iced::keyboard - Rust

3

At the moment the field key is used in the widgets.

The right alternative is the field modified_key.

The field text is a String (kind of) and doesn’t work well with the named keys like arrow keys.

I have not a problem with one of my apps. I am using the Cosmic desktop.
With the mentioned behavior change it stopped working well with my keybord layout. I try to find the best way to solve it before i crate issues and pull requests.

For me the best way is version (1.) “change the behavior back to the original way”, but perhaps there was a reason to change it. The reason is not mentioned in the commit message or linked issues.

The question is basically: what would a user of the iced lib expect when the key field is accessed. For me i would expect the key i type this should be my default. If i really want the baselayer and handle all different keyboard layouts myself it should be the special / uncommon one.

4

Sorry, I thought you had a problem with some code that you wrote. Reading the struct again, it’s not completely clear to me what the key field is supposed to hold. If we have physical_key and modified_key already, which are pretty clear, then what exactly is key? I think you do have a point here, but unfortunately I don’t have the answer.