[PULL libxkbcommon] Some more fixes and minor enhancements

[Daniel Stone]

Hi,

On 1 April 2012 16:31, Ran Benita <ran234 at gmail.com> wrote:
> On Tue, Mar 27, 2012 at 02:59:13PM +0100, Daniel Stone wrote:
>> >      Have a sane fallback strcasecmp
>>
>> Eh, if your system doesn't have strcasecmp, then I'm pretty sure it's
>> not my problem.  I've removed the fallback entirely.
>
> Always better. I assume strtok_r is fine as well? I've done a patch for
> that now.

Sure. :) It's been available in both Linux and BSD for some time now,
and is in 2001 POSIX, so why not.

>> >      Remove logging implementation boilerplate
>>
>> Funny you should mention this in your commit, I do actually have a
>> context API on the go which would allow you to do this properly, with
>> xkb_context_log_set_fd() and xkb_context_log_set_level().
>
> Hah, I've looked into that, but it seemed like too much messing around
> for a sunny weekend. Do you intend to replace all of the existing
> ACTION, WARN.. with proper logging? That would mean you'd have to get
> your context to all these places, and that seemed too much even for
> our friend xkb_desc.

Well, since an xkb_desc is necessarily generated from a context, it
would 'just' be a matter of an enormous regex, and then getting
indent/uncrustify to clean up the result.  But yes, definitely a job
for a rainy day. :)

> Also, I might as well mention that I rather like the following interface
> from the libabc demo library (it's public domain):
> https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git;a=blob;f=src/libabc-private.h
>
> Seems a bit better than a set_fd method, since the application may want
> to add its prefix or do some arbitrary crazy stuff.

Right, so allow it to call through arbitrary function pointers? I was
considering doing that, but wasn't particularly feeling like dealing
with the intracacies of varargs again that day.

>>     - add a refcnt into the mod/group sections for xkb_state so you
>> can use a single state object across multiple devices, provided they
>> share a keymap
>
> I've wondered (briefly :) about that, the interaction between different
> devices. Say that you hold Shift on one keyboard, should it affect the
> other? In the end I just used a single keymap with one state per device.
> So what's the expected behaviour with multiple keyboards? Maybe I should
> ask these guys: :)
> http://farm4.staticflickr.com/3164/3285787276_34bb157758_z.jpg
> http://www.arubaqth.com/Images/2010_large/R927xi_434_750.jpg

The answer is '??'.  It really depends; Wayland will want to share
state between all devices in the same group, X generates events twice
and keeps separate state for master (aggregate) and slave (individual)
devices, some people will want to keep state completely separate
across all keyboards, etc.  Since there's no universally correct
answer, I'd rather support both and let the user decide on the policy.

(The really comic one is when you have footpedals, for disabled users
to be able to trigger modifiers with a separate foot device, then type
keys on a normal keyboard!)

>>     - more warnings when compiling a keymap which uses
>> deprecated/removed functionality (e.g. message/redirect actions,
>> non-default key behaviours)
>
> Semi-related quastion: why did you leave the geometry bits in the
> parser? Would it not be enough to just skip the entire XkbFile if its
> type is geometry?

I'd like to be able to support full dumps (e.g. generated from xkbcomp
-xkb :0 foo.txt) being loaded in to xkbcommon without triggering
parsing errors because it doesn't have natural support for floats.
That was the best way I found to do that; is there something I'm
missing?

>> Did you have anything else in mind that you needed, especially with
>> the structs/macros having been sealed now?
>
> Well, since you ask :) Something I've done twice now already is to
> implement a keysym-to-unicode function, using either the imKStoUCS.c
> file from libX11 or the keysym2ucs.c file from Markus Khan:
> https://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c
>
> Would you consider importing one of these and adding a
> xkb_keysym_to_ucs4 or xkb_keysym_to_unicode function? It's not directly
> related to XKB but quite useful for the library users.

Yeah, absolutely, that'd be pretty useful indeed.  Bonus points for
(also?) having a xkb_keysymS_to_utf8. :)

Cheers,
Daniel