On Mon, Jul 9, 2012 at 10:51 PM, Rui Tiago Cação Matos <[email protected]> wrote: > On 9 July 2012 16:27, Aron Xu <[email protected]> wrote: >> I know your wish is good, so I said it looks elegant. But in real >> world it's not that easy to add another layer of abstraction as "input >> sources" here. > > Why? Can you please elaborate on this? >
So do you know what input method framework exactly do right now? You can't think it's purely something like an application in GNOME, it was a secondary class citizen but if you clearly understand how X server handles user input, then it's at a higher level than usual GNOME applications of the stack, which is at the same level of the X codes which handles user input. Input method is not a desktop environment's component, just like X, it's a system wide stuff. Users can lost some specific experience of a DE (say GNOME), but he/she must have the same input experience on every part of the system (maybe we can limit to X in the mean time), no matter if there is GNOME, KDE, *box or even pure Xlib/XCB applications. In this perspective, it's not GNOME to choose an input method to intergrate, it's GNOME's job to intergrate with current IMFs better (if you really want to make a difference). This also explains why you have found that all existing input methods tend to make themself cross platfrom, i.e. working with all kinds of applications and maintain many things by themselves. This is intended, this is what called user experience from a system designer's perspective, and it's true stuff that users rely on like X which should not be altered by a simple design assumption from GNOME. >> First of all, IMF is actually almost what you think as >> "input sources", and XKB may be a part of it. In this way users can >> switch between German XKB and Chinese (Pinyin) without problem because >> they are all under the management of the IMF. Such kind of work has >> been their for long in IBus, as you may know ibus-xkb. > > I do know about ibus-xkb and fcitx seems to also be growing that kind > of functionality. I just don't agree that that makes sense in an > integrated environment such as GNOME. Does GNOME offload its printer > settings to some external component? What about its display device > settings (monitor setups, resolution)? So why should we do it for > "input sources"? > It does not make any sense that you think an intergrated desktop enviroment like GNOME is able to handle the input events of the whole system, but input method frameworks are designed to do that. GTK+ currently does not pass all keyboard input to IMF first and it's proved to be broken (I see you may don't agree as you never met the problems, but if you are an IMF user, you might already meet them for quite some times). I've said that input method framework is something at a lower level in the desktop stack, so I would like to ask you some questions in the way you are asking me: Does GNOME load printer support from driver to configuration into its internal component? Dose GNOME load the whole stack of X into its internal component? For the questions you've asked me, I can answer that GNOME uses the interface provided by lower level software to configure printers, GNOME uses the interface provided by lower level software to setup monitors, and screen resolutions. GNOME should use the interface of IMFs to achieve better user experience, and you can push the interface being established and standarlized - it's just not too complicated, I'll talk about it later. > IMO, IM engines are useful to translate/compose symbols from user > input and an IM framework is useful so that we don't need to have > different code for each of Chinese, Japanese, Korean or others. But it > ends there. If you start offloading keybindings and other > configurations then how do you make sure that the UI will be > consistent with the remaining GNOME UI? > Yes, IM engines can be roughly though as "translators", but IM engine is not the thing we are talking, IMF will handle it for system-wide and user-wide usages, but not limited to GNOME in any mean. IM framework is not a tool for you to ease your work and implement a simple but does-not-work solution. You need to understand that IMF is something deeper in the system stack than GNOME. There are people proposed about the possibility of making a framework of IMFs, I'd rather make it clear that it should be a standard interface of IMFs, for various desktops to have better intergration with them. This standard interface should be consist of how configrations are exported, how keyboard shortcuts are managed, etc. It's not a complete list, but this interface should provide enough stuff for us to implement a nice UI and keyboard shortcut management because we have a way to communicate with IMF, just like what we have with XKB in X. Then GNOME can choose a team of IMF developers to work on "reference implementation", hardcoding one of any IMF is not feasible to fufill the needs. It's again hard to understand that why not an IMF can be good enough, or even why an IMF can hardly be improved to be good enough. At least it costs a lot of years... When you are using a keyboard, then the XKB mapping is in not about to change and you have almost no choice; but for input method users, they can always choose from different developers and vendors. If you are using mobile devices with iOS/Android, you might know that there are many vendors providing input methods, the basic functions are almost the same but you will have a preferred one for some details. This is also true on Windows and Linux, users are nit-picking and if you tried to limit their choice then he/she must be angry with you, :-) -- Regards, Aron Xu _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
