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 <[email protected]> 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 <[email protected]> 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: > [email protected]:bluetech/libxkbcommon.git contextualize > https://github.com/bluetech/libxkbcommon/tree/contextualize > Have a look when you've got time. > >> Cheers, >> Daniel > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
