2012/4/24 Sergey Udaltsov <[email protected]>: > 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?
IBus doesn't define layouts AFAIK. Its engines descriptions contain XKB layout names that I guess are the ones that work better with a given engine. For instance the pinyin engine says that the US layout should be used. So, in your example, xterm would just get the keystrokes as if they were coming from a US layout keyboard if the user chose the Chinese (Pinyin) method. > 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? No, I don't think xterm supports any kind of input method. xterm will just work as it works now. > Ok, that's fair. Except for pure IBus layouts - they cannot be > configured using setxkbmap, right? No, IBus only enters the picture if the applications actively support it. Of course, toolkits like GTK+ usually take up on that job so individual apps don't have to worry about it. What we do is instruct IBus to change its current engine when needed along changing the XKB layout. > 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... Well, if you're running GNOME 3 I'd say your computer can certainly handle that. >> 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? These aren't changing every month are they? Every once in a couple of years? I think we can just maintain a list of what's useful on the GNOME side. > 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. Honestly, if a user is locally editing stuff under /usr/share/X11/xkb, is he our target user? Remember that what I'm trying to do here is keyboard input configuration be hassle free. If something is missing that's needed by a relevant portion of users, of course it will get included. > So, even if the user would tweak the options using GUI - you keep the > options specified with setxkbmap at startup, right? Yes. > Even if the user > unchecks/checks "compose:ralt" checkbox? There's no "compose:ralt" checkbox at the moment. If it's deemed necessary we will add one (certainly not with that name) and we will override that specific option then. Rui _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
