|
在 2012年5月11日 星期五 21:00:35，Rui Tiago Cação Matos 写道： > On 11 May 2012 15:41, Vincent Untz <vuntz gnome org> wrote: > > There's been some recent discussion wrt input methods in openSUSE: > > http://lists.opensuse.org/opensuse-factory/2012-05/msg00169.html > > Thanks for bringing this to my attention. > > > Apparently, people seem to think that ibus is not the right long term > > solution. And fcitx has been mentioned several times, then the upstream > > author wrote this: > > http://lists.opensuse.org/opensuse-factory/2012-05/msg00205.html > > > > When reading this thread, it sounds to me that there are quite some > > users who are unhappy with ibus. So I'm wondering: have other approaches > > been considered? > > I didn't consider any other option since IBus seemed to work well > enough and has active maintainers. I also didn't know about fcitx but > its developer got in touch with me today which was nice of him (added > in CC). > > But let's go a bit deeper on this topic. There are a lot of IM > frameworks, it seems that everyone is starting their own and, to be > honest, I'd like this to end. It's actively harmful because it lowers > the chances of any of them actually becoming robust and polished > enough IMO. So, one thing I'd like to see here is more co-operation > between IM framework developers. People are, of course, free to do > whatever they want but that's my opinion. > > Then, all these projects try to do things in a cross-desktop way. This > isn't bad per se, but it creates several practical problems for an > integrated and cohesive environment like GNOME: > > - UIs which look alien; > - conflicts with the XKB configuration that GNOME does; > - conflicts with global GNOME key bindings; > - requiring to be explicitly enabled by the user or relying to be > started from X session scripts according to environment variables. > > Now, I think we all agree that this is far from a good user experience. > > I'm proposing a bargain to IM framework developers here. We are doing > all the UI and configuration for you and committing to maintain it > upstream, in an integrated way for GNOME. You are free to do whatever > you consider fit to support other environments. > > What I need from IM frameworks is basically: > > 1. a GTK+ IM module - these aren't a problem AFAICT since there's well > defined interface for them; > 2. a DBus API that I can use to enumerate engines, get some info about > them, switch and configure them; > 3. a DBus API to be implemented on the GNOME side that the IM > framework can use to present candidate windows. > > Right now IBus allows me to do all of the above so I'm sticking with > it for the time being. But, if IM framework developers agree on a set > of well defined interfaces for points 2 and 3 above I could port to > them. > > Rui
So let's kick it off.
Actually there is an such DBus API. And even more there are implementations. https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/master/show/applets/kimpanel/backend/ibus
https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/master/show/applets/kimpanel/backend/scim
(And notice they are not depends on any kdelibs, only some gio and glib.)
And I have a gnome-shell extension implementation for it. https://extensions.gnome.org/extension/261/kimpanel/
If ibus/GNOME is willing to adopt some of them, I can remove it from KDE side so there will be no duplication.
And BTW, im framework requires more, they need some custom icon and custom menu, not only the candidate windows.
And I agree that there should be and API to enumerate through engines. Current implementation is based on input method to call "ExecMenu", which is not so good.
Regards, Xuetian |
Attachment:
signature.asc
Description: This is a digitally signed message part.