[PULL libxkbcommon] Some more fixes and minor enhancements

[Ran Benita]

On Wed, May 09, 2012 at 06:20:35PM +0100, Daniel Stone wrote:
> On 9 May 2012 16:13, Ran Benita <ran234 at gmail.com> wrote:
> > On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote:
> >> 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 :)
> 
> Ah, crap, I didn't realise people actually used that outside of
> Windows.  Yeah, we can do both, I'll get to that RSN (after I've
> finished up some Wayland core stuff), and merge Kristian's keysym
> stuff at the same time.

Windows uses UTF-16, which is indeed crap. One-to-one mapping between
the encoding and the codepoint is nice sometimes (and it's what wchar_t
uses, outside of Windows at least).

> >> autotools makes me sad sometimes.
> >
> > Didn't know that; good that you caught it.
> 
> While we're here, the -I$(top_builddir)/src/xkbcomp is needed as
> parser.h is generated during the build; it's slipped out of your
> patches a couple of times and I've had to re-add it.  No biggie, but
> just so you know.

Yes, I didn't notice you reverted it the first time, although I was sure I
had changed it :) Anyway thanks for teaching me something (I usually just
rely on make distcheck working).

> >> 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.
> 
> Cool! Yeah, I like it and have merged it.  Hilariously, at almost the
> exact point in time (this morning, while I was on the train with no
> internet access) you were changing context to ctx, I was changing xkb
> (for xkb_keymaps) everywhere to keymap.  So I've merged this now but
> there were a pretty staggering amount of conflicts.  Still, I now have
> everything on your contextualize branch.
> 
> I think the only API issue I have now is renaming groups to layouts.
> There's still a few bits internally but hopefully we should be good to
> go pretty soon.
> 
> Since our trees seem to have mostly settled down by now, any
> objections to me running uncrustify after I merge the keysym ->
> Unicode stuff?

Absolutely no objections. It might even make the code in rules.c
readable :)

Thanks for merging and handling the conflicts!