Arch Linux

and gnome-settings-daemon need to change dependency to libibus.

Well, there seems to be a missing dependency, ibus should depend on the same version of libibus I guess...

update against arch's new update, fix the missing libibus dependency issue.

Any updates? Since gnome 3.6 is already pushed into extra, I'd like to see some feedback on this.

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?

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.)

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.

3.
- 1.4.99 is not stable, not only it breaks some version miss match, but some state out some problem here: https://bugs.archlinux.org/task/32381
- 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 (*).

4.
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.

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.

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.

@wonder:

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...)....

[1] http://comments.gmane.org/gmane.linux.arch.tur.user/26631

@wonder:

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).

[1] https://bugs.archlinux.org/task/32381

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: https://bugzilla.gnome.org/show_bug.cgi?id=685514), 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?

Please split -- an IBus contributor.

@wonder
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"

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.

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.

@wonder
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.

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].

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.

Implemented.
Packages currently in [testing].