D5301: Introduce support for keyboard layout switching policies

[Martin Gräßlin]

graesslin added a comment.


  In https://phabricator.kde.org/D5301#99777, @hein wrote:
  
  > On a very high level I'm a little bit worried we're going to make the same mistake as on X11 again, where we have invested a lot into keyboard layout smarts (a KCM, a dynamic indicator, things like this) that ultimately don't satisfy modern requirements and have caused us to fall behind on proper text input support. The KCM should be managing input languages instead of keyboard layouts (though an appropriate layout for the language does also matter), the indicator should reflect the active input language engine, and so on. Most other systems do this, along with featuring language-agnostic stuff like emoji input and typing-booster prominently in the system and its UI.
  
  
  We have different requirements here. We have the ASCII world and the non-ASCII world. All what I have been working on this release cycle is to bring the ASCII world up to the job of where it was on X11. All of this is to instrument xkbcommon on how the keyboard layout are to be set.
  
  Input methods (non ASCII world) is a completely different story and rather orthogonal to the work presented here. Yes I agree we could do better in the field of input methods, but we need people having a clue about it working on it. It does not make sense if I work on it as I have no clue about it.
  
  > Catching up to the state of the art should be on our minds ... is there anything you can think of here that would be worth making more generic at this point? Can this switching policy stuff later be subsumed by something higher-level that manages the layout?
  
  What I have done here is instrument xkbcommon. This has nothing to do with "higher level" mechanisms. As said above: it is orthogonal. Whether or not this can be "subsumed" by something higher level: I have no idea as I don't have any knowledge about this "higher level" stuff. I think it does not make sense as this here instruments xkbcommon and not some input method framework.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D5301

To: graesslin, #kwin, #plasma
Cc: hein, plasma-devel, kwin, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170404/9cb04123/attachment-0001.html>