On 11/28/2012 03:50 AM, Kristian Høgsberg wrote: > On Tue, Nov 27, 2012 at 03:11:17PM -0500, Kristian Høgsberg wrote: >> On Sun, Nov 18, 2012 at 07:06:41PM +0100, Jan Arne Petersen wrote: >>> From: Jan Arne Petersen <[email protected]> >>> >>>>>> 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. >>>> >>>> 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. >>> >>> I implemented it that way in this patch series. >> >> Yup, it looks fine now. I ended up moving a few things around in the >> weston-simple-im client. Mainly I removed the keyboard-utils.[ch] >> split and just included that in weston-simple-im, and removing the >> extra abstraction layer. The other change was making it not depend on >> toytoolkit. With these changes, I think weston-simple-im could be >> developed into a real-world table based IM. > > Oh, just realized a problem with the way we grab the keyboard: when > the IM grabs the keyboard, we block compositor keybindings. > Ctrl-Alt-Backspace and the debug bindings (Shift-Mod-Space S etc) > don't work while the editor fields has focus.
Oh yes, there is only ever one active grab. We could modify the default_grab in text-backend instead of using wl_keyboard_start_grab, but I am not sure that is a good solution. I will create a patch so we can see from there. Jan Arne -- Jan Arne Petersen Openismus GmbH http://www.openismus.com _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
