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.

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?

In 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.

Let me be clear I realize layout stuff needs to be done anyway, and I'm not criticizing the submission or want to kill your momentum. My intention was just to speak up on what our eventual goals for text input on Plasma need to be (move beyond layouts into input languages, manage a IME daemon, improve support for things like emoji input and typing-booster, etc.). That may not actually read on the patch, I just thought it might me helpful to keep in mind while putting infra for things like "change something about text input when switching virtual desktops" into place. Like I said, that's a very very high-level review.

(I'll add that on X11 the keyboard layout stuff is hairy - normally you have kwin/xkb doing things, but when you use ibus, it takes over keyboard layout management and you have to set xkb options through ibus (which means users who need ibus for an IME can't use any of the Plasma settings UI). Hopefully we can make that better in the Wayland world somehow.)

In D5301#99812, @hein wrote:

My intention was just to speak up on what our eventual goals for text input on Plasma need to be

I don't have any goals there as I don't have any idea of what is required. If I would put up goals I'm pretty sure that what comes out of it is completely useless for anybody who needs it.

(move beyond layouts into input languages, manage a IME daemon, improve support for things like emoji input and typing-booster, etc.).

I can tell you only for emoji that this cannot work through normal keyboard input. There are neither key codes nor key symbols representing emoji. Thus it's not possible to use the wl_keyboard interface for them. This probably needs to go through a variant of text input and is thus completely orthogonal to the work done here.

(I'll add that on X11 the keyboard layout stuff is hairy - normally you have kwin/xkb doing things, but when you use ibus, it takes over keyboard layout management and you have to set xkb options through ibus (which means users who need ibus for an IME can't use any of the Plasma settings UI). Hopefully we can make that better in the Wayland world somehow.)

That's of course problematic and shows the general problem of apps not working together on X11. On Wayland that won't work as the compositor is the only one who can setup xkb.