On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote: > On Sun, 11 Mar 2018 20:30:14 +0100 > > Carlos Garnacho <carl...@gnome.org> wrote: > > This new protocol description is a vast simplification over v2, highlights > > are: > > - All pre-edit text styling is gone, the protocol doesn't seem the place > > > > to convey UI state. Clients are in better knowledge of how to make the > > pre-edit string distinguishable from regular text. As an long-time input method developer and CJK user, I'd prefer to keep the styling. In Chinese or Japanese, partially converted text are common and styling is useful to help user to distinguish which text is currently being converted. [1] But for the sake of in-app consistency, I'd say we don't need that much capability about styling though. Among all input methods supported by fcitx [2], only underline/highlight is being commonly used. Recently I started to use some strike style in only one single input method though, it can also be useful in certain cases.
> > > > - No input panel (OSK) state nor covered rectangle events. This leaks > > > > assumptions about the coordinate space of windows, and clients aren't > > fully capable of handling all possible situations (eg. if the OSK fully > > covers the surface). At the very least it could be split into a generic > > protocol of its own, this version of the protocol simply doesn't get > > into this business, compositors are still free to handle situations > > where > > the keyboard focus rectangle is covered by the input panel. > > > > - Less state is to be kept on compositors. Clients must now reissue all > > > > applying IM state whenever the surface gains focus (or internal focus > > changes), instead of state requests being independent from focus. > > > > - No set_preferred_language request for clients, modern desktops have > > > > generally moved towards session-wide IM settings, it seems hard to > > conciliate this piece of information flowing in both directions. > > > > - There is no event to send keysyms. The handling ought to be by all means > > > > identical to wl_keyboard's, compositors might just use that interface. Let input method itself to send any key event is somewhat an important feature. Common use cases includes "sending backspace key via OSK", or "simulating another keyboard layout". Fcitx (5, which is under developlment) provides ability to use a keyboard layout without changing the system global layout, which can be extremely helpful for users using multiple layout. For example, the hotkey key binding would keep the same while they can still using the custom layout (e.g. position of ctrl + z is different under us/de). I assume that you mean that it is replaced by creating sythatical key event via compositor and sending them via wl_keyboard? I'm not so sure if that works, especially when there is no real phyiscal keyboard. [1] https://i.imgur.com/MpibNVi.png [2] https://fcitx-im.org/ _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
