The ability of changing state on the fly is an essential part of Chinese input experience. So we have both embedded menu and language panel in IBus 1.4 previously.
I used to believe that IBus 1.5 enforce the first form and and no longer support second form. That's fine for me, though some people may miss it. However, why the menu in keyboard status menu become something that requires engine specific hacks? I saw one for anthy. https://bugzilla.gnome.org/show_bug.cgi?id=682314 http://git.gnome.org/browse/gnome-shell/commit/?id=9659d934ac190a6363fc5b59f3c62ef305f56c52 What about ibus-chewing, ibus-pinyin, ibus-table and probably other engines especially 'third-party' ones then? Without property menu they are much less useful in practice. If you have concerns the property texts, other things about 'supported' engine, why don't you contact IBus upstream and request for change? For third-party engines, they should have freedom to do whatever they want, rather than blocked by some hard-coded filter. Stop destroying IBus by making it GNOME-proprietary, please. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
