[PULL libxkbcommon] Some more fixes and minor enhancements

[Ran Benita]

On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote:
> Hi Ran,
> Sorry for the delay, have been sidetracked by core Wayland stuff for a bit.

Hi!

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

Yes, but I think having UCS-4 makes sense as well, by which I mean that
are applications (mine..) which have good reasons to use it. Since the
existing implemantations (the libX11 one and the Markus Kuhn one)
convert to uint32_t anyway, why not expose it in addition to UTF-8? So
when you implement it please have a UCS-4 one :)

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

Didn't know that; good that you caught it.

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

Of course I didn't take a compiler class yet and so I hadn't realized
yacc does bottom-up parsing, making this impossible... (at least in a
straightforward way)

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

I have done this now. I've kept backward compatibility by just treating
them as xkb_keymap in the parser. See the branch below.

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

This sound good. I might try it some day.

Finally, I had some time today to finish some stuff I started to remove
more global state. It wasn't very fun but I managed to move
xkb_intern_atom and friends into the context. I've now also put the
patch mentioned above, and as always tried to sneak in a stylistic
change :) It's based on your recent master:
        git at github.com:bluetech/libxkbcommon.git contextualize
        https://github.com/bluetech/libxkbcommon/tree/contextualize
Have a look when you've got time.

> Cheers,
> Daniel