From: Jan Arne Petersen <[email protected]> >> text: Start input method from configuration
> I'm happy to see this functionality land, but there's few comments on > the patch. I fixed the comments on this patch. >> text: Rename and extend text_model key event > I'm holding off on this one and the remaining patches. I think you're > right that it's better to just add the events to text_model, but > there's more to it than that. We need a better approach to modifiers > than what you have in the keysym event. It needs to be compatible > with the wl_keyboard modifier model. That's a bitmask too, but you > need the xkb keymap to understand what the bits mean > (xkb_map_mod_get_index). So we could add a keymap event to > text_model, but it's a little expensive to send out and re-parse the > xkb map, so I'd rather the text_model could grab it from the > associated wl_keyboard (from wl_seat in text_model.enter). I'd also > rather use a modifier event like wl_keyboard than send the modifiers > with each keysym event. > > Now if we use the keymap from the associated wl_seat, have a modifier > event and the keysym event, do we still need text_model.get_keyboard? > Do we ever need the key codes at this level? And if we do, can we > just get them from the real wl_keyboard? That is, send out the > keycode from wl_keyboard interface and the keysym from text_model? > > Hmm, and if we rely on wl_keyboard in text_model (for the keymap) > should we just get modifier events from wl_keyboard as well? That is, > we only add the keysym event to text_model and keymap and modifiers > come from the underlying wl_keyoard. Yes, we do not need the get_keyboard request in text_model, we can just send that key events over the underlying wl_keyboard (via default_grab). Which makes it much easier on the client side. So I removed that. With the modifiers there is the problem, that when the keysym events are generated by a virtual keyboard there is no underlying wl_keyboard and keymap available for the wl_seat to get the modifiers bitmask (xkb_keymap_mod_get_index). And I do not think it would make sense to add an extra keymap for a virtual keyboard just to define the modifier indices in a keymap. Additionaly one does not really want to process the modifiers via xkb_state because a virtual keyboard usually handles it own state and would just send effective modifiers anyways. For this patch I tried out to reuse the modifier bitmask from the keymap when available. But it does not seem to be the right way to do it especially since one would need to define some fallback values for the case when no keymap is available. My current idea would be to add a modifier_names event to text_model, so that an input method sends an array of known modifier names (which would be the same used by xkb_keymap_mod_get_index). The mapping to a bitmask is than just done by the index of that modifier name in the array. Regards, Jan Arne Jan Arne Petersen (8): text: Start input method from configuration text: Rename and extend text_model key event text: Send more information with keysym events text: Add support for grabbing the keyboard text: Add support for forwarding key events window: Add utils for xkb keyboard input window: Allow to get xkb context from display text: Add simple compose input method Rob Bradford (1): editor: Add support for editing text using the keyboard clients/.gitignore | 1 + clients/Makefile.am | 13 +- clients/editor.c | 144 +++++++++++++++---- clients/keyboard-utils.c | 173 +++++++++++++++++++++++ clients/keyboard-utils.h | 67 +++++++++ clients/keyboard.c | 56 ++++++-- clients/weston-simple-im.c | 338 +++++++++++++++++++++++++++++++++++++++++++++ clients/window.c | 24 ++++ clients/window.h | 6 + protocol/input-method.xml | 32 +++++ protocol/text.xml | 14 +- src/compositor.c | 5 +- src/compositor.h | 10 +- src/text-backend.c | 286 ++++++++++++++++++++++++++++++++++++-- weston.ini | 3 + 15 files changed, 1107 insertions(+), 65 deletions(-) create mode 100644 clients/keyboard-utils.c create mode 100644 clients/keyboard-utils.h create mode 100644 clients/weston-simple-im.c -- 1.7.11.7 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
