[PULL libxkbcommon] Some more fixes and minor enhancements

[Ran Benita]

On Tue, Mar 27, 2012 at 02:59:13PM +0100, Daniel Stone wrote:
> Hi Ran,
> 
> On 24 March 2012 15:24, Ran Benita <ran234 at gmail.com> wrote:
> > There's some unrelated groups of commits here. I've tried to arrange
> > them such that they can be picked selectively if needed.
> 
> Great stuff, thanks.  I've pulled most of it, aside from:
> 
> >      Remove remaining uses of X11/X.h modifier masks
> >      Duplicate the *MapIndex defines from X11/X.h
> 
> I'm planning to remove X11 modifier stuff completely, so virtual mods
> are the only modifiers exposed through the API.  Since some modifiers
> are more useful than others (e.g. you want your keybindings to be
> sensitive to the Alt vmod, but not really Left Alt and Right Alt),
> this would also give an xkb_map_mod_is_primary() flag that specifies
> whether or not you should ignore it.
> 
> Either way, the static masks are on their way out.

Sounds great.

> >      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.

> >      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.

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.

> > And this is just to make my group switching work. Since it was #ifdef'ed
> > away, I assume it's not so simple, but from some testing I did it works.
> >      Handle group lock actions
> 
> Oh, it probably is that simple, I just hadn't got around to checking
> it.  (Nor have I checked modifier latching ...)
> 
> > (Sorry for the code-dump style of this; I can only work on this on the
> > weekend and holding off seems kinda silly.)
> 
> No problem, it's all great stuff! I'll try to push at ~end of the day,
> thanks again.  Sorry in advance about the conflicts -- some of it
> conflicted with other stuff I'd committed since you branched, and some
> are caused by the selective cherry-picking.
> 
> In terms of what I have coming up, aside from the context API and vmod
> merging, I've got a branch that actually adds multiple-keysym support
> that I just need to fix up and put in.  After that, my rough TODO list
> is (rough because I just lost my actual TODO file in a tragic vim swap
> file accident):
>     - add support for a ~/.xkb/rules.local and ~/.xkb/keymap.local
> which would override any definitions in the compiled rules and keymap,
> respectively
>     - 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

>     - 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?

>     - xkb_map_foreach_mod() and xkb_state_foreach_active_mod() API +
> the group equivalents
>     - some other stuff which I've subsequently forgotten ... damnit ...
>     - any additions/changes needed to make a GTK+ port work ;)

> 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.

> Cheers,
> Daniel

Thanks!
Ran