Hi, On 13 July 2012 16:55, Keith Packard <[email protected]> wrote: > Dan Nicholson <[email protected]> writes: > >> Not that I actually have the time to work on this, but I'd been >> thinking about xkbcommon lately. Do you think it's possible to build a >> compatibility layer around the current code? > > I don't know, but I'd be surprised if xkbcommon provided enough > low-level information to support the existing XKB protocol. I hope > Daniel can answer this question...
Here's what I sent earlier about this, but it appears to have been lost in transit: I realise it seems a bit counterintuitive, but yeah, I don't think we can really support it. The problem is that the server -- due to wonderful things like xmodmap -- needs to be able to just obliterate random parts of the keymap on the fly. There's quite a bit of server code to support this, which we've had to pull in to xkbcommon to have it generate an even remotely coherent map (rather than just half-complete) for clients. Stuff like actually binding virtual modifiers to real modifiers and thus having working types. :) In terms of what we need for the server, the API surface area is, well, pretty much the entire source tree. I don't think that's really sustainable as a library. My goal with xkbcommon's changed to be able to provide a useful and easy keyboard handling library, with a clear, simple, and supportable API. One of the tradeoffs I had to make there was making the maps immutable, which to be honest I'm completely fine with. I'm also hoping to use it to experiment with other, more comprehensible, file formats, and I don't think that's doable if the entire library is wide open to clients to mangle. As a happy side effect of this, we can now see what clients are actually _doing_ with the keymap and thus find out which bits we really need to support. I still think having (something like) xkbcommon in the library is a really good idea, but I just don't see much benefit in sharing the library, given the two wildly disparate usecases. I'm hoping to fix it up to at least import maps from an X connection, so we can have all clients (be they X, Wayland, DirectFB, whatever) using xkbcommon, and just the X server using its own special codebase for its own special requirements. I hope I haven't completely run your project into the ground! >> What do you think? It seems silly not to be making use of xkbcommon in >> X. > > That was the plan, but then the plan also included replacing XKB with > XKB2, which was supposed to have vastly simplified XKB... I realised that step one was working out what people were actually using out of it. Also, given that it was pretty much impossible to use without copy and pasting (literally) thousands of lines of code into your app, we needed something more self-contained where you could say: - build me a keymap - I just pressed this key, what now? and, err ... that's about it really. Cheers, Daniel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
