[PATCH v3 0/9] Hardware keyboard input for input methods v3

[Jan Arne Petersen]

On 11/27/2012 09:11 PM, Kristian Høgsberg wrote:
> On Sun, Nov 18, 2012 at 07:06:41PM +0100, Jan Arne Petersen wrote:
>> From: Jan Arne Petersen <jpetersen at openismus.com>
>>
>>>>>   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.
> 
> I've committed the patches as-is, but please keep lines under 80
> characters; introduce temporary variables instead of building up
> several nested calls and break inner loops into helper functions if
> the nesting gets too deep.

Yes, sorry the weston-simple-im client would have deserved one or two
more rounds of cleanup before submitting. I will create a patch to make
it a bit nicer.

Jan Arne

-- 
Jan Arne Petersen
Openismus GmbH
http://www.openismus.com