An Intelligent Input Bus

Edit Package ibus

IBus is an Intelligent Input Bus. It is a new input framework for Linux OS.
It provides full featured and user friendly input method user interface.
It also may help developers to develop input method easily.

Source Files (show merged sources derived from linked package)
Filename Size Changed
20-defaults-openSUSE.conf 0000000143 143 Bytes
README.SUSE 0000003323 3.25 KB
_multibuild 0000000054 54 Bytes
baselibs.conf 0000000992 992 Bytes
hide-setup-menu.patch 0000000389 389 Bytes
ibus-1.5.29-rc2.tar.gz 0003991416 3.81 MB
ibus-autostart 0000000281 281 Bytes
ibus-autostart.desktop 0000000233 233 Bytes
ibus-complete-preedit-signals-for-postprocesskeyevent.patch 0000002469 2.41 KB
ibus-disable-engines-preload-in-GNOME.patch 0000000937 937 Bytes
ibus-enginesimple-dont-commit-any-characters.patch 0000002970 2.9 KB
ibus-fix-Signal-does-not-exist.patch 0000000513 513 Bytes
ibus-socket-name-compatibility.patch 0000007669 7.49 KB
ibus-ui-gtk3-restart-via-systemd.patch 0000006218 6.07 KB
ibus-xim-fix-re-focus-after-lock.patch 0000000511 511 Bytes
ibus.changes 0000057800 56.4 KB
ibus.spec 0000015389 15 KB
im-engines-precede-xkb.patch 0000000723 723 Bytes
macros.ibus 0000000745 745 Bytes
setup-switch-im.patch 0000002757 2.69 KB
xim.d-ibus-121 0000001572 1.54 KB
xim.ibus.suse.template 0000000739 739 Bytes
Comments 5

Marguerite Su's avatar


Can you please explain why python3-ibus was dropped? I read the changelog, but I didn't understand the "upstream will not maintain it for python 3" sentence. if so, why upstream still accept my ibus-force-python3.patch?

As we know, openSUSE is disgarding python 2.x, and that's why @qzhao dropped ibus-sunpinyin and ibus-googlepinyin from openSUSE:Factory. If ibus upstream "will not maintain it for python3", then python-ibus will be dropped soon because the engines require it have been dropped.

@qzhao actually I tested the python3-ibus in Leap 15.0, after patching "import gobject" further, it's usable. I also tested ibus-sunpinyin (because I think it's still been using by our users), it worked well with python3-ibus and python3-gobject2 without any modification since it's really a small setup program.

So I think here's the thing:

ftake and qzhao are different in view. qzhao wanted to follow our python 2.x removal progress while ftake wanted to keep python-ibus as it is.

both have troubles for now. for ftake, python-ibus will be dropped anyway. for qzhao, you didn't test if some engines are portable...



Fuminobu Takeyama's avatar


At the previous update, I specified a new flag --disable-python2 introduced by the upstream. Then, that flag removes what we have called python3-ibus.

Now Python application can communicate by using IBus gobject introspection without python3-ibus. So only legacy application, which is/was written in Python 2, might be using that library.

So I asked "Do we still need python3-ibus?" before submitting the previous update. ibus-sunpinyin still requires python3-ibus? Is it possible to remove that dependency by patching to ibus-sunpinyin?

Fuminobu Takeyama's avatar

Sorry, I just asked do we still need python(2)-ibus.

Fuminobu Takeyama's avatar

About "ibus-force-python3.patch", "--disable-python2" allow us to build ibus without python2. And the patch was not merged as it is, implemented different way.

Cliff Zhao's avatar

Sorry, could you please show me the discussion record of my opinion? My memory of the context was a little hazy.

openSUSE Build Service is sponsored by