Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#32071 - [ibus] split into ibus and libibus, in order to not affect other imf user on gnome

Attached to Project: Arch Linux
Opened by Weng Xuetian (csslayer) - Thursday, 18 October 2012, 22:03 GMT
Last edited by Allan McRae (Allan) - Sunday, 05 January 2014, 04:03 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 12
Private No


Related info:

GNOME will set environment var that prevent other imf (fcitx, gcin, uim, blablabla...) work with XIM and Qt application if ibus-daemon is installed, other distribution doesn't matter that much since ibus-daemon is in a separate package, so I propose split ibus and libibus in different package, thus other user can use other IMF.

Remove ibus dependency from gnome-settings-daemon will lose feature for ibus user (it's a compile time option), so it's not an optimal solution.

Additional info:
* ibus-
* gnome-settings-daemon 3.6.1-2

Testing done, no problem. all compiles.
This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 05 January 2014, 04:03 GMT
Reason for closing:  Implemented
Additional comments about closing:  ibus-1.5.4-2 in [testing]
Comment by Weng Xuetian (csslayer) - Thursday, 18 October 2012, 22:04 GMT
and gnome-settings-daemon need to change dependency to libibus.
Comment by Yichao Yu (yuyichao) - Friday, 19 October 2012, 20:13 GMT
Well, there seems to be a missing dependency, ibus should depend on the same version of libibus I guess...
Comment by Weng Xuetian (csslayer) - Thursday, 25 October 2012, 11:24 GMT
update against arch's new update, fix the missing libibus dependency issue.
Comment by Weng Xuetian (csslayer) - Wednesday, 31 October 2012, 12:24 GMT
Any updates? Since gnome 3.6 is already pushed into extra, I'd like to see some feedback on this.
Comment by Ionut Biru (wonder) - Saturday, 03 November 2012, 13:11 GMT
i don't see any reason to split anything. What is wrong with the current ibus implementation? Why do you feel the need to use other imf?
Comment by Mantas Mikulėnas (grawity) - Saturday, 03 November 2012, 13:30 GMT
Ionut: Things like custom ~/.XCompose entries, for example, only work with the `xim` input module. (The default GTK input module harcodes them at compile time.)
Comment by Weng Xuetian (csslayer) - Saturday, 03 November 2012, 13:36 GMT
1. it's not about which one is better. If it affects existing user, it needs to be solved.

2. other imf appears a better choice other than ibus for some user, some Simplified Chinese user prefer fcitx, some Traditional Chinese user prefer gcin or hime, some Japanese user may use uim.

- 1.4.99 is not stable, not only it breaks some version miss match, but some state out some problem here:
- gnome's integration introduce a white-list for ibus, which hides some necessary im for some people.
- It can be only used as a global state under gnome, which is not a good solution for multi language user, which mean they cannot use different language under different window.
- function difference (*).

If you want to comparing in more detailed way, I can list a long list functional difference, would you like to see that? If you want to argue why these can also be done in ibus,
I. it's not done.
II. Techinally there is some prevention from underlying architecture difference between all imf, some function is just "can not be done without hack, or even hack is impossible".

As for packaging, split it:
1. didn't break anything. All existing user will not be affected.
2. Make easier for user to switch.
And it will make everyone happy.
Comment by lilydjwg (lilydjwg) - Saturday, 03 November 2012, 13:50 GMT
Ionut Biru: Why are you using Linux instead of Windows? Why do you make Arch Linux? What is wrong with all other Linux distributions?

Just because they are DIFFERENT, and offer users CHOICES.
Comment by Ionut Biru (wonder) - Saturday, 03 November 2012, 14:48 GMT
I'm not an user of ibus or other imf that's why I'm asking this questions.
I'm trying to understand what is the actual problem and how to resolve it for our users, with the minimal effort.
The solutions that you guys proposed is a nightmare and it would increase maintenance of packages.

@lilydjwg, if you start with comments like this, i'm going to close this bug as won't implement and move over with me life. It doesn't affect me.
Comment by Yichao Yu (yuyichao) - Saturday, 03 November 2012, 15:09 GMT

So if you r not using any imf, please don't make it impossible for users who need input method everyday to choose a imf they like (this is also the reason why those gnome ppl who don't use input method *AT ALL* made this stupid integration).

If you are interested in why other imfs are more advanced than ibus or why all these imf's should be supported, please have a look at the discussion here[1] when ibus was orphaned a few weeks ago.

AFAIK, the only thing the gsd ibus-integration does now is breaking every input methods for everyone. So if u r looking for a ``simpler'' way to make it work for everyone, we can just disable the compile time option (of gsd). If gnome does sth some even more stupid to make ibus impossible to work under gnome-shell without the integration in the future (hopefully not, since it will very like make ibus impossible to use out of gnome...) let's find another solution at that time, but the only working way in that case is probably to split libibus, which I actually don't really think is a nightmare (I'm not a packager so plz correct me if I am wrong on this...)....

Comment by Yichao Yu (yuyichao) - Saturday, 03 November 2012, 15:18 GMT

BTW, even if we decide to keep the integration, we may have to disable it now (before a stable version of ibus is released) since ibus 1.4.99 (and it's input methods for this version) is said to be buggy and really unstable. (I'm using Fcitx so I have no personal idea about this.) Please see discussions in this bug[1] as well as similar bugs on the bug tracker and related threads on the forum (about ibus-* is breaking).

Comment by Weng Xuetian (csslayer) - Saturday, 03 November 2012, 16:15 GMT
The problem is every imf is conflict with each other, and being selected with three environment varible, XMODIFIERS, GTK_IM_MODULE, QT_IM_MODULE, which affects non-gtk/qt app, gtk application, and qt application.

Gnome settings daemon forcily set two environment variable, XMODIFIERS and QT_IM_MODULE under gnome session if ibus-daemon exists on the disk (related code:, which means, if ibus is installed, non of other imf can be used correctly under non-gtk app in gnome. Or even people don't want to use ibus or any other IMF at all, it's not possible. Using ibus with Xim will make non-gtk-qt application cannot use Compose/Dead key, due to xim and xcompose limitation.

So the only way so solve this right now is either disable ibus with g-s-d at all, or split ibus into different package. One of the "make-sense" split is that split it into libibus and ibus, which is done by all other fine-grained packaging distribution.

Yes, this will introduce some complexity into packaging, but we already have all other distribution as reference so it's not a big deal, no?
Comment by Ma Xiaojun (damage3025) - Saturday, 10 November 2012, 19:23 GMT
Please split -- an IBus contributor.
Comment by Tom Yan (tom.ty89) - Wednesday, 14 November 2012, 13:58 GMT
For the reason why some people don't ibus, it's quite similar to that of pulseaudio (in my opinion).
But for the reason why should it be splited, it's more like that of having different desktop environment and window manager in the repo.
Well, but of course you can say, "if you don't like ibus, you shouldn't use gnome"
Comment by Ionut Biru (wonder) - Wednesday, 14 November 2012, 14:02 GMT
currently we do not have an ibus maintainer. I'm not willing to touch this packages.
Please apply to became a contributor if you want to see this issues resolved.
Comment by Jan de Groot (JGC) - Wednesday, 14 November 2012, 14:25 GMT
As a user who doesn't care about input methods at all, I think our best option is to disable ibus integration for now and wait for ibus 1.5 and GNOME 3.8. ibus integration is nice, but if it doesn't work like intended, nobody is ever going to use it.
Comment by Tom Yan (tom.ty89) - Wednesday, 14 November 2012, 14:37 GMT
Personally I use ibus only. I am not interested in switching to another imf. But for now it's indeed broken. I would say that it's silly for GNOME to have ibus integration while nothing real has been done.
I do recognize you are not obliiged to fix this. I just hope to let you understand why some are so anxious about this issue. IMF is crucial to CJK users, but I do think that we do not contribute enough.
Comment by Weng Xuetian (csslayer) - Wednesday, 14 November 2012, 15:57 GMT
The problem is it's in [extra], a new TU Felix Yan can take care of it (while he already take care of other ibus-* package in [community]), but he only has privelledge to update [community].
Comment by lainme (lainme) - Wednesday, 11 September 2013, 17:32 GMT
The problem still exists, since the script /usr/lib/gnome-settings-daemon/gnome-settings-daemon-localeexec set QT_IM_MODULE and XMODIFIERS enviroment variables once if /usr/bin/ibus-daemon exists in disk, inregardless of the gnome-settings-daemon's keyboard plugin is activated or not. The keyboard plugin only determine whether the ibus daemon should be started on startup, not whether the enviroment should be set.
Comment by Felix Yan (felixonmars) - Sunday, 05 January 2014, 03:31 GMT
Packages currently in [testing].