Closed FloVanGH closed 1 year ago
I used to think that keys cannot be represented by a char
and therefore the keys should always be a string instead of a char.
But i now have my doubts. Maybe char
is actually enough?
Edit: Note that even if we keep char, we should remove the Copy bound because of future possible events such as compose events
Tobias was the last person to have input on this in the previous PR:
https://github.com/slint-ui/slint/pull/1747#issuecomment-1308448798 https://github.com/slint-ui/slint/pull/1747#issuecomment-1308543169
One compelling argument I see is that Apple went for a string as well: https://developer.apple.com/documentation/uikit/uikey/3526130-characters
A key can return more than one char. E.g. Ä
has a compatibility encoding of one char Ä
, but the official encoding is A
followed by a two dots above
character. Depending on system configuration a keyboard may return one or the other.
To prevent #1747 to introduce a braking change by using
SharedString
for key event text what make it necessary to removeClone
derive fromWindowEvent
, char will be used now. It should be replaced bySharedString
for 0.4.