|
APR
6
2017
|
Complex text input in Plasma Surprisingly not enough A brief note: If you're a developer or user of input methods in the free desktop space, or just interested in learning about "How does typing Chinese work anyway?", you might be interested in a discussion we're now having on the plasma-devel mailing list. In my opening mail I've tried to provide a general overview about what input methods are used for, how they work, who they benefit, and what we must do to improve support for them in KDE Plasma. Bringing high-quality text input to as many language users as possible, as well as surfacing functionality such as Emoji input and word completion in a better way, is something we increasingly care about. With the situation around complex text input on Wayland and specifically KWin still in a state of flux and needing-to-crystallize, we're looking to form closer ties with developers and users in this space. Feel free to chime in on the list or hang out with us in #plasma on freenode. |
 |
Comments
Comments
Mailing lists are a little outside my repertoire for interacting with unfortunately.
It's exciting to see unifying efforts like this, and I hope this works out well.
Your message covered a lot of ground, and I want to pick out one of your statements:
> * KWin-assist (dynamic layout switching) needs to think in
> input languages, not keyboard layouts.
To this, I must vociferously disagree. The system as it is already awkwardly includes qwerty and colemak and dvorak under 'US', which leads to usability problems when I forget to change the qwerty and colemak to display as 'qw' and 'cm', nevermind the fact that I'm from Canada and don't like to look at a 'US' in my taskbar. I'm also fearful of a system as broken as the current localisation system. The fact is, I cannot on a current Linux system get dates, times and numbers to all be formatted correctly—the system's focus on the 'country' as the source of truth for all these other settings may be useful for defaults, but it leaves me unable to interact with my system properly. I do not want to see this mistake further repeated. To simply replace layout with language throws away important information, and builds a system that cannot serve the user. And serving the user is important here. I'm certain you're aware of issues here that I cannot see, that are better solved by tagging the language, but treating such a large cohort as uniform without distinction is prone to problems. I wish I could wait to speak until it's clear exactly what kind of impact this would have, but I fear I need to be vocal early lest I get the shaft again as badly as I did with localisation which I've spent hours trying to fix.
> To simply replace layout
> To simply replace layout with language throws away important information, and builds a system that cannot serve the user.
Agreed, and we wouldn't go for a ham-fisted approach like that :). (I also agree that grouping those layouts under "US" is wrong, pretty much from any semantic angle.)
The point about thinking in input languages instead of layouts - and if you prefer you can call it input sources or input contexts instead - is mostly about the fact that switching layouts isn't enough, as both the input method engine and the layout for it may need to be switched (at the very least tiered, or possibly independently). That, and the settings UI currently being geared towards layouts only, which are simply only one aspect to complex input.
There's a need to instill that the problem of input has a scale beyond keyboard layout, because handling a key press doesn't end there.