Bug 962181 - Integrated IBus Considered Harmful
Integrated IBus Considered Harmful
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-12 07:01 EDT by taehyun kang
Modified: 2013-05-13 05:50 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-13 05:50:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description taehyun kang 2013-05-12 07:01:40 EDT
as of Gnome 3.6, Ibus is integrated into gnome shell. although this could give some people a false sense of software integrity/completeness, as a user I have to point out that utterly unusable is the integrated ibus, for following reasons:

1. remarkablely slow(!) input-method switching speed

 -> after upgrading from FC17 to FC18, one can immediately notice that there is an additional one second+ delay between switching input methods. Gnome 3.6 is the only operating system environment that punishes user with such delay. Because of this delay workflows of users relying on more than one input methods are severely disrupted. It has to be noted that im-switching delay had been nonexistent in history of gnome/linux (and many input-method applications, not only ibus) before integrated ibus became the sole method of managing input-methods.

2. new and inferior ibus configuration 

 -> following is a list of features that were possible in old "Ibus Preference", with no functional equivalent in new ibus:

 1) multiple hotkeys to switch to next/prev input methods (because gnome hotkey setting is inferior.)
 2) using shift- as a modifier for a im-switching hotkey (because gnome hotkey setting is inferior.)
 3) using a physical input method switch key in non-english keyboards as a im-switching hotkey (because gnome hotkey setting is inferior.)
 
 -> also, because ibus-daemon is executed by gnome shell, there is no way to 'restart fucking everything' to solve im-related problems. 

3. proposed solutions

 1) revert back to non-integrated ibus.
 2) sudo yum groupinstall xfce
Comment 1 fujiwara 2013-05-13 03:30:04 EDT
(In reply to comment #0)
> as of Gnome 3.6, Ibus is integrated into gnome shell. although this could
> give some people a false sense of software integrity/completeness, as a user
> I have to point out that utterly unusable is the integrated ibus, for
> following reasons:
> 
> 1. remarkablely slow(!) input-method switching speed

I don't understand your problem exactly.
It's good to provide the reproducing steps.
However I think your problem is fixed in the latest ibus.

# yum install --enablerepo=updates-testing ibus

> 
> 2. new and inferior ibus configuration 
> 
>  -> following is a list of features that were possible in old "Ibus
> Preference", with no functional equivalent in new ibus:
> 
>  1) multiple hotkeys to switch to next/prev input methods (because gnome
> hotkey setting is inferior.)
>  2) using shift- as a modifier for a im-switching hotkey (because gnome
> hotkey setting is inferior.)
>  3) using a physical input method switch key in non-english keyboards as a
> im-switching hotkey (because gnome hotkey setting is inferior.)

These issues are not ibus.
Transferring to gnome-settings-daemon.

>  -> also, because ibus-daemon is executed by gnome shell, there is no way to
> 'restart fucking everything' to solve im-related problems. 

If you wish to restart ibus. ibus command utility is available:

% ibus restart

> 
> 3. proposed solutions
> 
>  1) revert back to non-integrated ibus.
>  2) sudo yum groupinstall xfce

It's good to file bugs before you think the options.
Comment 2 Rui Matos 2013-05-13 05:50:17 EDT
(In reply to comment #0)
> 1. remarkablely slow(!) input-method switching speed
> 
>  -> after upgrading from FC17 to FC18, one can immediately notice that there
> is an additional one second+ delay between switching input methods. Gnome
> 3.6 is the only operating system environment that punishes user with such
> delay. Because of this delay workflows of users relying on more than one
> input methods are severely disrupted. It has to be noted that im-switching
> delay had been nonexistent in history of gnome/linux (and many input-method
> applications, not only ibus) before integrated ibus became the sole method
> of managing input-methods.

We know about this. GNOME 3.8 should already be better in this regard and there's still another fix that we'll land before F19.

> 2. new and inferior ibus configuration 
> 
>  -> following is a list of features that were possible in old "Ibus
> Preference", with no functional equivalent in new ibus:
> 
>  1) multiple hotkeys to switch to next/prev input methods (because gnome
> hotkey setting is inferior.)

It's possible if you edit gsettings directly. The UI (g-c-c) doesn't expose this capability though.

>  2) using shift- as a modifier for a im-switching hotkey (because gnome
> hotkey setting is inferior.)
>  3) using a physical input method switch key in non-english keyboards as a
> im-switching hotkey (because gnome hotkey setting is inferior.)

These require specific bug reports. We do have reasons to not allow certain key combinations, basically to try to avoid people losing access to regular keys, but those can be improved if we get good bug reports.

>  -> also, because ibus-daemon is executed by gnome shell, there is no way to
> 'restart fucking everything' to solve im-related problems. 

Takao was courteous enough and answered you already.


Now, I must say that the tone of this "bug report" is not acceptable and you are lucky I'm in a good enough mood to take the time to reply to it. Bugzilla is for specific bug reports and should be kept technical in nature.

I'm closing this. Please try F19 at your convenience and file specific bugs upstream.

Note You need to log in before you can comment on or make changes to this bug.