On Wed, May 09, 2012 at 06:20:35PM +0100, Daniel Stone wrote: > On 9 May 2012 16:13, Ran Benita <[email protected]> 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: > > [email protected]: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! _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
