[PULL libxkbcommon] Some more fixes and minor enhancements

[Daniel Stone]

Hi Ran,
Sorry for the delay, have been sidetracked by core Wayland stuff for a bit.

Thanks a bunch for all your last changes too, I've merged everything
except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests.  Again
for the Unicode tests I want to use UTF-8 rather than UCS-4 and will
get to this really quite soon now I promise (finally have some time to
poke back at xkbcommon).

As for the DFLT_XKB_CONFIG_ROOT change, it's ugly as sin but
unfortunately it's the only way for it to work properly, since just
substituting from within configure doesn't always perform enough
expansion.  On some versions you'll be left with the string being
"${datarootdir}/share/X11/xkb" or similar.  The 'fix' there is to just
do more rounds of expansion, but the upstream-recommended method is
actually to do it as we're doing it now, believe it or not.

autotools makes me sad sometimes.

As for the rest -

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

Yeah, the tests look really good and we should definitely be doing
that, I'm going to merge in a really minimal dataset too so we're not
relying on an installed dataset for all our tests.  At that point we
can go all-out and throw in a lot more tests for esoteric stuff like
locking modifiers.

I don't know if I'll have too much time to poke at the log stuff
anytime soon, but it definitely sounds good.

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

Hmm.  If it works then it'd definitely be a net win. :)

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

No, we can jettison the other two.  In theory we need them for
compatibility, but in reality they don't exist and I don't care.

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

Yeah, I think we should have a global file and a per-user override
too.  I'd like to see the following be possible:
    * xkbrc (or something): set the default names, which would allow
us to pass NULL to the compilation functions and get the default
    * rules.local: amend the rules file
    * keymap.local: amend the compiled keymap

This way hopefully no-one even remembers xmodmap exists.

Cheers,
Daniel