Hi, I'm glad to see you are participating public discussion on this issue.
On Mon, Jul 9, 2012 at 10:02 PM, Rui Tiago Cação Matos <[email protected]> wrote: > On 9 July 2012 15:41, Aron Xu <[email protected]> wrote: >> In Rui's patches, he defines some shortcuts for switching between XKB >> and IBus. This looks elegant, but it's problematic because IBus have >> already defined all kinds of shortcuts, as well as users may change >> many of them to fit their preference. The actual effect here is that >> IBus can hardly catch shortcuts and cannot be reactivated when the >> user switched to XKB, which is painful. > > It's true that IBus ships its own UI and keeps its own settings > including keyboard shortcuts. But, one of the goals for this > integration is to define GNOME settings and shortcuts for what makes > sense to be in GNOME and expose them in GNOME UI like System Settings > and gnome-shell. One of those is the shortcut to switch among > configured "input sources" which allows you to switch between say a > plain German XKB layout and Chinese (Pinyin). > 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. 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. The functionality is still limited because we CJK developers don't use it everyday like you do, but I am sure that if you are willing to adapt to this solution then things will improve very quickly. Adding another layer of abstraction is making the input module on Linux much more complex, and most importantly make users more likely to be confused. I agree that exposing IBus's settings in a consistent way like other applications in GNOME may improve user experience if we've done it wise, but please don't go further before you actually get used to what's IMF and how users make use of it day by day, it's just too risky and both you and design people need to talk more to CJK users and developers. I guess you've learned that input method is really something different from the long but not productive discussion before, even if you might still don't understand it well till now. >> Finally, because the patches is still sitting in wip branch, I don't >> think it's approperiate to report bugs to the application itself. > > This should change soon and I'd be really thankful if you gave it a > try then and give us feedback on it. > > Rui I will try my best to avoid current code to be merged, and please don't do it if you really don't want to see so much CJK users being disappointed by a decision that you have made in house with a few guys don't actually know what is it. -- Regards, Aron Xu _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
