Arch Linux

(4) is a duplicate of  FS#32293 .
And for (1)(2)(3), could you kindly link to upstream issue, or report one if there isn't? Thanks.

it's marked unstable upstream, and it at least unstable if not utterly unusable.

it does not start automatically; its input method's configuration can not be opened if we don't re-compile the package with additional configure switches; even if the input method's configuration opens, the configuration itself does not work.

i think the best answer would be rolling ibus and all related packages back to stable version.

I agree to roll the ibus related packages to the stable version.
At least i roll these packages to stable version using ARM.

The UNSTABLE version of ibus is not like the CyanogenMod nightly builds or git kernel,
it's definitely not fit for daily use.

Please roll back these packages until next stable version comes out.

Just a note for those who don't know, if we roll back ibus to the stable version. gnome-setting-center needs to be recompile as well (and disable the stupid ibus-integration compile option) since the current version in [extra] is linked against libibus......

$ pacman -Qs ^ibus
local/ibus 1.4.2-2
Next Generation Input Bus for Linux
local/ibus-pinyin 1.4.0-1
The PinYin Engine for IBus Input Framework.
local/ibus-qt 1.3.1-5
IBus qt library and IBus qt input method plugin

this is working find, although when installing there's some strange warnings. i'm not using gnome-setting-center, thanks to the stupid gnome 3.

and the current repo ibus setting ui looks unacceptably ugly on both of my xfce desktops.

EDIT: i guess the ugliness is caused by the lack of gtk3 version of clearlooks. i reverted back to clearlooks from adwaita because of the sudden ugliness of adwaita after the last upgrade.

Same to Auguste,
I'm using Openbox, the gnome things does not affect me.

Also the ugly 1.4.99 UI seems not the problem with GTK3 theme.
Zukitwo themes works both fine with any gtk3 or gtk2 UI but only the 1.4.99 ibus is ugly.

I'm wondering why the problem is not found, shouldn't these packages(ibus and the gnome-setting-center) be tested in test repo before moving into extra/community?

I use Openbox with the dvorak keyboard it seems like the by default it take qwert layout which is really not working. have to setxkbmap evertime i start.

ibus 1.4.99 is not stable.

1.4.99 unstable cannot work with openbox. ibus-setup dont remember my settings, and make keyboard dull.

While I don't see all problems mentioned in this report, I also came to the conclusion that ibus 1.4.99 is completely unusable for me. My main issue is that ibus seems to ignore all settings I make in the setup interface (they are set in dconf though), which leaves me with the default set of hot keys for activation, method switching, et cetera, clashing with a lot of software I use (Emacs...). So I'd also highly appreciate if ibus was downgraded to a stable version.

1/2. The most starred issue at IBus upstream.
http://code.google.com/p/ibus/issues/detail?id=747
3. I didn't get the exact meaning.
4. ibus-anthy is kind of weird in a sense that it has 1.2.7 then 1.3.99 then 1.4.99.
I don't know why but I encourage people to ask in ibus-user or ibus-devel, but I'm sure that ibus-anthy's developer is following that two mailing list (Google Group).

For other stability/UI/whatever issues, I encourage people to ask in ibus-user or file a new issue in IBus upstream. I'm definitely following and would help CC the origin developer if needed.

To add compatibility with probably older engines, please add --enable-python-library when compiling. Since older engines are still using "ibus" Python module and haven't been ported to GObject Introspection.

As I checked today, ibus-anthy and ibus-pinyin is already upgraded so they should be OK now.
ibus-hangul has GI port but hasn't released a new version yet.
https://github.com/choehwanjin/ibus-hangul/commits/master
And ibus-table hasn't GI port yet, even its 1.4.99 releases don't support GI.

To Ma Xiaojun

Why I reported the task is NOT to report the ibus-related bugs,
but to report the problem of the packaging things.(Of course these things should be reported here)

The version dismatch of anthy and other modules is NOT the upstream problem because the time I reported the task,
there is already corresponding ibus-pinyin and ibus-anthy upstream, but the ibus-anthy is not the same version in community repo when I reported the bug.

In my opinion, the unstable version of ibus 1.4.99 is nearly UNUSABLE(not only for the ibus-lib dependency but also the bugs),
so the packager should not include this version os ibus into community/extra repo.
Also the when packaging gnome-control-center, the stupid ibus-integration compile option should be disabled.

@Adam

Not sure if it is the right place to say this, but if you want to use older version of ibus along with gsd (which u will need to compile youself), I have uploaded a gsd package[1] with ibus-integration disabled in aur (I definitely need it since I need to test fcitx and ibus and gs from time to time..... and enable this option means either I cannot test ibus anywhere, or I cannot easily test fcitx in gs....) that is not depending on any ibus packages even if are compiling it with ibus installed. (It's out-of-date now because I don't have the access to the latest gsd PKGBUILD....)

[1] https://aur.archlinux.org/packages/gnome-settings-daemon-noibus/

To Yichao Yu

Thanks, but I've already rolled back the ibus related package to the stable version using ARM.
Since I'm an openbox user, the gsd does not affect me.
(Just because the gsd in extra is compiled against the 1.4.99 ibus, so the gsd needs to change)

@Adam
> In my opinion, the unstable version of ibus 1.4.99 is nearly UNUSABLE(not only for the ibus-lib dependency but also the bugs),
> so the packager should not include this version os ibus into community/extra repo.
> Also the when packaging gnome-control-center, the stupid ibus-integration compile option should be disabled.

Despite 1.4.99's version number, it has been included in Fedora 17 and unstable branch of other distributions for a while. It's definitely not something entirely new and untested.

If you have specific issues or opinions about design choices about IBus 1.4.99, you should definitely contact the upstream. It's not good that new software introduce new bugs or break existing workflow, but that's not a strong point of downgrade. It's arguable the KDE 4 and GNOME 3 also introduced many new bugs and broke existing workflow, but we eventually package them and probably use them.

And if you are concerned about g-s-d, it's not the topic of this task, right?

To Ma Xiaojun

Yes you're right about F17 and other distributions.
Also since Archlinux is always on the bleeding edge, new feature and new bugs is somehow acceptable.

In this point, I know these packages will not be rolled back at a high possibility.

But the packaging strategy of the ibus-related packages is the real problem.
ibus1.4.99 breaks the anthy and pinyin for a few days, other modules may take a much longer time to recovery.

Should not these packages be released together or have a version related dependency flag in the PKGBUILD since they really depend on specific version of ibus?

I would +1 for --enable-python-library in [extra]/ibus. Otherwise it seems ibus-table* and other modules affected may be dropped from [community] until they implement GObject Introspection.

@damage3025
Update: I've opened a new issue specially for this:  FS#32556 , please correct me if there are any errors in my understanding and/or statement.

To all:
Please test if there are still problems, thanks!

Enable/Disable hotkey is not functional. Still cannot assign next input method hotkey. But mozc is now activating properly from the left click menu.
On the side note, the previous build did not disturb the xkb, now however, when the daemon is launched I loose all the setxkbmap options when I switch the language and I have to manually reset the xkbmap. Is anyone else experiencing a similar issue?

@platforma
Thanks for the feedback, though this should be a new issue upstream =)

@alex m: I experience that, xkb and ibus override each other.

Any setting changes done to ibus-pinyin using the GUI is not saved.
and ibus-pinyin is unable to type the word "yuan", only recoginzed as "yu" and "an".(Upstream problem)

Also Mozc needs to be recomplied for the lib dependency(Not a bug).

I don't see any item of ibus-table detected after installing it and even reboot.
For chewing, still can't get the config window. (Probably another upstream issue?)
By the way, thanks for adding the libpinyin package, Felix. I need to use Quail in Emacs before that since GNOME 3.6!

I guess anthy is the only one really works (perfectly) with the unstable ibus.
Upgrading to it doesn't seem making any sense while most engines are unavailable. (Especially if it affects non-gnome users.)
I don't see why should it be even released on the ibus official page.

Quail again. ibus support has been disabled in gsd.

At this time, I think the best option is using ibus-stable in AUR.

Since ibus is no longer used in GNOME (for now) is there a reason *not* using stable?
I had the feeling it was bumped to an unstable version in order to get it to work better in GNOME and not any other reason.
Why stay with it if thats the case?