Hello Sergey, thanks for your input.
2012/4/24 Sergey Udaltsov <[email protected]>: > 1. What about non-gtk apps not having IBus integration? How are they > going to be supported? Say, good old motif;) So, gtk+ apps thankfully are able to switch the input method that they use at runtime just by listening to an XSETTING and I'm doing that already. 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... 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. > 1.1. How do you plan to provide network transparency without switching > layouts on X server level? 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. > 2. Actually, libxklavier and libgnomekbd are useful not only for > switching, but for some other things. For example: > - (libxklavier) reading xml registry supplied by xkeyboard-config > - (libgnomekbd) providing keyboard layout preview > Are these bits going to be reimplemented from the scratch? 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. 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. > 3. How are you going to address the fact that some international > layouts can be alternatively implemented using XKB and Ibus? Will you > let user choose? How will you explain him the nature of that choice > (purely technical detail)? I'm leaning on just providing a flat list to users on the UI like: - English (US) - Japanese 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. If there's enough demand and it makes sense to add an entry we will do it. Input from our translators and i18n people on what is popular enough to make it to that list would be great for this. > I am all for integration of IBus and XKB, but it is important to make > it properly, without sacrificing the habits of existing userbase - and > with proper support of good X11 citizen apps, even if they are not > blessed by the modern toolkit. People can still use whatever xmodmap, setxkbmap, etc. hacks they want. Some of them will even work with this system like for instance 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. Some things might not work and I'm willing to evaluate how to best support them on a case-by-case basis. It might very well be that for some really exotic stuff the answer might be to just disable gnome-settings-daemon's keyboard plugin in gsettings and then the user is free to whatever on his own. Rui _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
