[PULL libxkbcommon] Some more fixes and minor enhancements

[Ran Benita]

On Mon, Apr 02, 2012 at 12:04:25PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 1 April 2012 16:31, Ran Benita <ran234 at gmail.com> wrote:
> > 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.

Varags aren't so bad. I had some fun abusing them here:
https://github.com/bluetech/libxkbcommon/blob/tests2/test/keyseq.c
That said, you can look at the libabc example code, if you think that's
a better approach.

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

Hmm, if I get it right, floats etc, can only appear inside xkb_geometry
sections (which we treat as files). So the scanner should be able to lex
them, but the parser can just skip the section and not have to know
anything "inside" it. I'm not sure yacc does that off hand, I'll try it.
Of course, it may be worth keeping for completeness or whatever.

Another question than :) We currently support three types of "aggregate"
files, which are xkb_keymap, xkb_layout and xkb_semantics. The keymap
can include all components (i.e. keycodes, symbols...), and the other
two only one or two (mandatory / optional - see XKBcommonint.h
#defines). Looking in /usr/share/X11/xkb, the layout type is completely
unused, and there are a couple semantics files (which seem unused). So,
is it worth keeping those? I don't think they serve any useful purpose?
(unless someone tries to load them, but I don't think anyone has them
lying around).

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

And lastly (I promise :), I'm thinking about a situation where there are
several users of the library (say xserver, wayland/weston, kmscon,
toolkits) and they all load a keymap from an rmlvo. Currently it seems
like the end user would have to configure her preferred rmlvo separately
for each one, which can get annoying (already..). Since you mentioned
loading files from ~/.xkb/, would it make sense to support some simple
config file for that? That way if the end user didn't explicitly
override through the application, and the config file exists, it should
be used as the default instead of some "us" layout.

And if it makes sense, should libxkbcommon be the one doing it anyway?

Thanks!
Ran