Hi Rui > Everything else will continue to work (or not work) as it does now I'm > afraid. The imsettings package in Fedora takes care of setting up some > environment variables according to the user's locale at login time > which should continue to work. Of course any switching the user does > at runtime won't be picked up... My question was about layouts that are implemented through ibus, but not xkb. For example, if user chosen Chinese IBus layout - what's going to be entered into xterm? Will XKB layout be "converted" on the fly from IBus layout?
> That said, it's my understanding that the IBus developers have a way > to workaround that problem with the XKB simple engines for IBus which > should basically allow us to always direct these "legacy" apps to use > IBus for input and then IBus will just forward the symbols it gets > from the key press events unmodified. Err, I am not sure I understand the process completely. Does that mean IBus sets up some "proxy" that converts X events before they reach xterm? > The layout is switched at the X server level. The code I have now is > doing the equivalent of running "setxkbmap <layout>" whenever the user > triggers a switch. I don't think network transparency is hindered in > any way here. Ok, that's fair. Except for pure IBus layouts - they cannot be configured using setxkbmap, right? And, of course, there is a question of performance - invoking setxkbmap (even calling corresponding XKB APIs) is so much more expensive than changing current group in X server... > Right, no. The keyboard layout previews I'm planning to do by just > calling the gkbd-keyboard-display utility from libgnomekbd so there's > still a runtime dependency on it for this specific tool. Fine. > I don't think we'll need to read the xml registry for anything at this > point. But if the need arises I'll probably just use libxklavier for > that of course. How are you going to find out what layout are available from XKB? > And maintain a table of XKB layouts and IBus engines that each of > those entries translates to. The user won't be faced with arbitrary > choices of layouts, variants, options or IBus engines. We will provide > what's most sensible. I am opposite to that. If the user adds layout/variants to xkeyboard-config, he wants these layouts to be available. I already have bug reports about not showing "extra" (more exotic) layouts - but at least that is switchable with a single gsettings key. I am trying to be sensible in separating "core" from "extras" - but at least if something managed to get into "core" - it is visible immediately. Neither libxklavier nor libgnomekbd nor g-c-c filters those materials - all filtering is done in xkeyboard-config (and it is easy to switch on/off). By putting extra filter, you make the process more difficult - people will have to change two places, xkeyboard-config and your code (will it be compiled-in or put into some xml file?). The process becomes not transparent. > if you just run "setxkbmap -option compose:ralt" on a session startup > script we won't undo that even if you are switching layouts during > that session. So, even if the user would tweak the options using GUI - you keep the options specified with setxkbmap at startup, right? Even if the user unchecks/checks "compose:ralt" checkbox? Regards, Sergey _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list