[PATCH libxkbcommon] Add xkb_key_get_action API

[Ran Benita]

On Tue, Mar 27, 2012 at 02:27:49PM +0100, Daniel Stone wrote:
> On 24 March 2012 15:03, Ran Benita <ran234 at gmail.com> wrote:
> > - Some way to update the state according to a given led state, i.e. say
> >  the app is starting with the Caps Lock led on, I'd like to update the
> >  modifier state according to the indicator map. Right now there are
> >  only getters in the new API.
> 
> This should be fairly straightforward for most LEDs, which only
> reflect the state of a single locked modifier or group.  For LEDs
> which reflect multiple states though, which modifiers/groups do you
> choose, and for LEDs which reflect effective state, which state
> component do you choose?

I'll admit to only care about locked modifiers, i.e. XkbIM_UseLocked.
XKB, being XKB, probably allows for some crazy stuff with the poor LEDs;
I haven't used them, nor do I know how other people use them, so I can't
comment further.

> I'm tempted to say that we only deal with the straightforward case,
> and don't bother with the other case at all, so then your call would
> look like:
> 
> {
>     xkb_led_mask_t led_mask = (1 << xkb_map_led_get_index(xkb, "Caps Lock"));
>     xkb_led_index_t led;
> 
>     xkb_state_update_led_mask(state, led_mask);
>     for (led = 0; led < xkb_map_num_leds(xkb); led++)
>         set_led(xkb_state_led_index_is_active(state, led)));
> }
> 
> That way xkbcommon could make a best-effort attempt to get the state
> in sync with the LEDs, and the user could then update the LEDs to
> match the new state.
> 
> If that sounds sensible I'll knock that up too.

Given the above, looks good to me.

> > - Some help with handling key repeat events. I'm not sure what the scope
> >  of this (if any) should be, but there is some stuff like the key
> >  repeat control and per key repeat. Should any of this be exposed?
> 
> Yeah, I'm really not sure what the answer is here.  I'm tempted to say
> that we should probably add an extra out parameter to
> xkb_state_update_key, being the repeat time, but it seems a bit icky.
> There's also the AccessX stuff to consider (sticky keys, debouncing,
> etc), which should also pass a notification back to the application to
> let it know what's happened.  My current thought is to put that in the
> state and let applications clear it, so perhaps repeats could be put
> there as well?
> 
> I guess the alternative is to change xkb_state_update_key to return an
> int: -1 meaning that the key should not be sent (e.g. due to AccessX
> slowkeys/debouncing), 0 meaning that the key should be sent and does
> not repeat, and a positive value specifying the time in milliseconds
> until the key should repeat.
> 
> Ideas?

Having the accessibility features built into the library would certainly
be cool. I did intend to try and write a soft repeat implementation. But
the evdev one worked well enough. Perhaps I should try now, and
than I'll have further thoughts about the interface. However at first
glance it seems like the state solution would be needed for the required
flexibility.

Thanks,
Ran