![]() ![]() ![]() The input method requests a grab on the wl_keyboard.Īll keyboard events are then sent to the input method exclusively instead of to the client of the surface currently having keyboard focus. Surrounding Text and other metadata like the cause for a change of the surrounding text.This is data the compositor actually does not do anything with but only conveys between the clients. The compositor needs to create such context information on its own That can be for example per window or application. Input method providers might want to set different options depending on the context, When another client is asking for text input (via the text-input protocol). In regards to activation of the selected input method client: the compositor informs the client Which input method client is selected to serve input methods is defined by the protocol.Ĭurrent protocols all follow a first come first served policy. Areas of Compositor Involvementįundamentally we can identify the following areas of compositor involvement in current input-method protocols: Selection and Activation That previous protocols might have overplayed the role of the compositor for input method supportĪnd more should be done by clients without any compositor involvement via Wayland protocols. It was recently suggested on IRC #wayland To interact with the compositor (via input-method-unstable-v1 and v2). Input method support in Wayland has always required CJK input method providers (fcitx, IBus)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |