On Wed, 11 Apr 2018 11:26:22 -0700 Weng Xuetian <wen...@gmail.com> wrote:
> 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. I think this use case is covered. For indicating what's currently being changed, this protocol is using "preedit string". In GTK, the preedit text is displayed with an underline, making is always clear what the suggestion pertains to. > > > > > > > - 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. > I read it the same way. At the same time, I also don't see a reason to duplicate the keyboard interface in another protocol - the compositor can tell the application that there's a regular (but virtual) keyboard connected and send events using the regular wl_keyboard protocol. Cheers, Dorota > [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
pgpRmKAG0n8Bi.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
