[PULL libxkbcommon] Some more fixes and minor enhancements

Wed May 9 09:10:57 PDT 2012

Hi Ran,

Let me just point you to this branch as well:

  http://cgit.freedesktop.org/~krh/libxkbcommon/log/?h=keysyms

I've been talking with Daniel about this in IRC, but I thought you
might want to take a look too.  With those patches the API is
completely self-contained.  We still need xproto, kbproto and
Xfuncproto at compile time, but none of that leaks through the
exported API.

Krisitian

On Wed, May 9, 2012 at 11:13 AM, Ran Benita <ran234 at gmail.com> wrote:
> 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
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel