RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 616061 - can't disable gtk XIM to use gtk-im-context-simple
Summary: can't disable gtk XIM to use gtk-im-context-simple
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: imsettings
Version: 6.0
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jens Petersen
QA Contact: QE Internationalization Bugs
URL:
Whiteboard:
Depends On: 505100
Blocks: 623931 659134
TreeView+ depends on / blocked
 
Reported: 2010-07-19 14:52 UTC by Andrew Overholt
Modified: 2011-05-19 11:52 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Using the im-chooser tool, XIM cannot be disabled as the default GTK immodule. Disabling input-methods using im-chooser and restarting the desktop session will still result in GTK applications using the XIM immodule. Consequently, using the Ctrl+Shift+U key combination to the directly input of Unicode characters from their hexidecimal code will not work. To work around this issue, use im-chooser to enable ibus. Enabling ibus permits gtk-im-context-simple's Unicode input and compose sequences to be used.
Clone Of:
: 623931 (view as bug list)
Environment:
Last Closed: 2011-05-19 11:52:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0521 0 normal SHIPPED_LIVE imsettings bug fix update 2011-05-18 17:57:51 UTC

Description Andrew Overholt 2010-07-19 14:52:47 UTC
Description of problem:
Can't enter unicode characters with Ctrl-Shift-u

Version-Release number of selected component (if applicable):
ibus-1.3.4-1.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL 6
2. Try to enter a unicode character with Ctrl-Shift-u <unicode code>
  
Actual results:
No unicode character entered

Expected results:
Unicode character entered

Additional info:
halfline says that the problem stems from gtk-im-module being set to 'xim':

$ gconftool-2 -R /desktop/gnome/interface | grep gtk-im
 gtk-im-status-style = callback
 gtk-im-preedit-style = callback
 gtk-im-module = xim

If I "yum remove ibus im-chooser" and then create a new user, things are as I would expect.  This is what got removed:

  Erasing        : ibus-sayura-1.2.99.20100209-2.el6.x86_64                1/13 
  Erasing        : ibus-rawcode-1.3.0.20100421-2.el6.x86_64                2/13 
  Erasing        : ibus-anthy-1.2.1-1.el6.x86_64                           3/13 
  Erasing        : ibus-qt-1.3.0-1.el6.x86_64                              4/13 
  Erasing        : ibus-pinyin-1.3.8-1.el6.x86_64                          5/13 
  Erasing        : ibus-hangul-1.3.0.20100329-1.el6.x86_64                 6/13 
  Erasing        : ibus-chewing-1.2.99.20100317-2.el6.x86_64               7/13 
  Erasing        : ibus-m17n-1.3.0-1.el6.x86_64                            8/13 
  Erasing        : ibus-table-additional-1.2.0.20100111-4.el6.noarch       9/13 
  Erasing        : ibus-table-1.2.0.20100111-4.el6.noarch                 10/13 
  Erasing        : ibus-gtk-1.3.4-1.el6.x86_64                            11/13 
  Erasing        : ibus-1.3.4-1.el6.x86_64                                12/13 
  Erasing        : im-chooser-1.3.1-1.el6.x86_64                          13/13 

Removed:
  ibus.x86_64 0:1.3.4-1.el6           im-chooser.x86_64 0:1.3.1-1.el6

Comment 2 RHEL Program Management 2010-07-19 15:17:48 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 fujiwara 2010-07-20 04:01:42 UTC
GTK xim doesn't implement Ctrl-Shift-u.

There are three ways.
1. Set GTK_IM_MODULE=ibus and no any ibus engines.
   Run im-chooser and enable IBus. (you need ibus, ibus-libs and ibus-gtk only)

2. Uninstall all GTK IM modules (ibus-gtk and gtk2-immodule-xim) then you will use GTK_IM_MODULE=gtk-im-context-simple
   You could check /etc/X11/xinit/xinput.d/none.conf

3. Add your $HOME/.xinputrc
% cat $HOME/.xinputrc
XIM=none
XIM_PROGRAM=
XIM_ARGS=
GTK_IM_MODULE=gtk-im-context-simple
QT_IM_MODULE=xim
IMSETTINGS_IGNORE_ME=yes
DISABLE_IMSETTINGS=yes

Probably I'll close this bug.

Comment 4 Andrew Overholt 2010-07-20 12:29:34 UTC
Thanks for the explanation.  I am concerned, though.  Ctrl-Shift-u is incredibly useful and well-documented online.  Is the default in RHEL 6 really going to be xim which doesn't implement Ctrl-Shift-u?

Comment 5 fujiwara 2010-07-21 02:16:13 UTC
> Is the default in RHEL 6 really going to be xim which doesn't implement Ctrl-Shift-u?

I think the default is ibus but not xim if you install input-method you don't setup anything.
You could configure option 1 in comment #3.

Comment 6 Jens Petersen 2010-07-21 02:36:01 UTC
The current workaround I can see are removing gtk2-immodule-xim
or enabling ibus.

I don't see a good solution though: gtk2-immodule-xim is
needed for Brazilian and European users to be able to use
full X locale compose input.

From UX POV using unicode input is wrong - it means our
desktop input system is incomplete.  And that should be fixed
not unicode input bandaids IMHO.

Comment 7 Jens Petersen 2010-07-21 03:53:30 UTC
Any change should be made first in Fedora.

Comment 8 Jens Petersen 2010-07-21 03:56:52 UTC
(In reply to comment #4)
> Ctrl-Shift-u is incredibly useful and well-documented online.

It is a toolkit specific hack really - I think it only works for GTK, right?

Comment 9 Jens Petersen 2010-07-21 08:18:14 UTC
I believe current behaviour is at least consistent across X, GTK, and Qt.

Comment 10 Akira TAGOH 2010-07-21 08:54:26 UTC
Sure. so what do you suggest to get this fixed in imsettings?

Comment 11 Ray Strode [halfline] 2010-08-02 19:16:01 UTC
(In reply to comment #6)
> The current workaround I can see are removing gtk2-immodule-xim
> or enabling ibus.
Removing gtk2-immodule-xim might make sense.  I think xim is pretty much legacy at this point right?  We'll have to make sure whatever is setting the gconf key stops setting it to xim as well though.

> I don't see a good solution though: gtk2-immodule-xim is
> needed for Brazilian and European users to be able to use
> full X locale compose input.
I don't think that's true.

> From UX POV using unicode input is wrong - it means our
> desktop input system is incomplete.  And that should be fixed
> not unicode input bandaids IMHO.    
Not always.  People use the feature for putting a pirate on irc or whatever.  I suppose we could add 

compose+yarrr = ☠

but ctrl-shift-u is useful and it should probably work out of the box...

Comment 12 Owen Taylor 2010-08-02 19:18:51 UTC
(In reply to comment #6)
> The current workaround I can see are removing gtk2-immodule-xim
> or enabling ibus.
> 
> I don't see a good solution though: gtk2-immodule-xim is
> needed for Brazilian and European users to be able to use
> full X locale compose input.

This is not fully true. The situation is that the default compose sequences, in, say, a en_US environment, do the obvious thing for certain compose sequences, in particular:

 dead_acute + c => c with an acute accent

Brazilian users tend to want something else:

 dead_acute + c => c_cedilla

[ Brazilian users are the heaviest users of compose sequences in the world, because of the predominance of the us-intl keyboard among technical users there. ]

If the locale (in particular, LC_CTYPE) is set to any language that uses a Cedilla (pt, fr, tr, etc), then GTK+ defaults to a input method module that acts appropriately (called im-cedilla, as I recall)

Now, unfortunately, we don't have any way of setting the locale categories independently through the UI, so if you want English messages with compose sequences (or currency, date formatting, etc) from a locale with a differnet language, there's no easy way to do i:

Using XIM via gtk-im-module=xim:

 * Causes a large performance and memory hit at startup - the XIM compose sequence mechanism was designed for a few dozen compose sequences, not the hundreds or thousands that are in it currently.

 * Breaks various features built into the default GTK+ input module as described above

If we want Cedillas, then we could specify:

 gtk-im-module=im-cedilla 

And get that behavior without the other downsides of XIM. I don't see any point in taking away control-shift-u for our default set of applications on the default desktop just make it more consistent with other toolkits.

Comment 13 Jens Petersen 2010-08-05 03:17:29 UTC
I refer to the long discussion in bug 505100 where this came up in Fedora.

(In reply to comment #11)
> I think xim is pretty much legacy at this point right?

I am not suggesting to use XIM for input-methods, just leveraged
the XIM code path for X locale compose.  This gives consistent
user input experience across gtk, qt and X applications.

> but ctrl-shift-u is useful and it should probably work out of the box...    

I didn't say it is not useful - I said it is wrong UI. :-)

(In reply to comment #12)
> If the locale (in particular, LC_CTYPE) is set to any language that uses a
> Cedilla (pt, fr, tr, etc), then GTK+ defaults to a input method module that
> acts appropriately (called im-cedilla, as I recall)

Right, but that only works in gtk apps.

> Using XIM via gtk-im-module=xim:
> 
>  * Causes a large performance and memory hit at startup - the XIM compose
> sequence mechanism was designed for a few dozen compose sequences, not the
> hundreds or thousands that are in it currently.

Hmm - agree that is bad.

>  * Breaks various features built into the default GTK+ input module as
> described above

Ok, but I am arguing that such toolkit specific features are
not really a good thing.

> If we want Cedillas, then we could specify:
> 
>  gtk-im-module=im-cedilla 

That only works for pt_BR users.

> And get that behavior without the other downsides of XIM. I don't see any point
> in taking away control-shift-u for our default set of applications on the
> default desktop just make it more consistent with other toolkits.    

I dunno at least it is consistent.

Perhaps a compromise would be to only enable XIM for locales where
X locale compose is needed, leaving the rest of us in peace? :)

We should probably make such a change first in Fedora 14 but guess we
can also try it for RHEL 6.0.

Comment 14 Jens Petersen 2010-08-17 06:18:33 UTC
There an update now in testing for F14:
https://admin.fedoraproject.org/updates/imsettings-0.108.1-2.fc14

Comment 16 Jens Petersen 2010-09-06 02:36:02 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
* Cause
    Due to an oversight it is not possible to disable XIM
    as the default GTK immodule from im-chooser.
    Turning off input-methods in im-chooser and restarting the desktop
    session still results in GTK applications using the XIM immodule
    by default instead of gtk-imcontext-simple.
* Consequence
    It is not possible to input Unicode characters directly by
    hexidecimal code using Ctrl+Shift+U.  On the other hand
    X locale compose sequences work correctly.
* Workaround
    Use im-chooser to turn on ibus, which supports
    gtk-imcontext-simple's Unicode input and compose sequences.
    Alternatively remove the imsettings package to allow using
    gtk-imcontext-simple but this will also remove all other
    input methods from the system.
* Result
    With the above workarounds gtk-imcontext-simple can be used

Comment 17 Jens Petersen 2010-09-06 02:41:32 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -3,16 +3,16 @@
     as the default GTK immodule from im-chooser.
     Turning off input-methods in im-chooser and restarting the desktop
     session still results in GTK applications using the XIM immodule
-    by default instead of gtk-imcontext-simple.
+    by default instead of gtk-im-context-simple.
 * Consequence
     It is not possible to input Unicode characters directly by
     hexidecimal code using Ctrl+Shift+U.  On the other hand
     X locale compose sequences work correctly.
 * Workaround
     Use im-chooser to turn on ibus, which supports
-    gtk-imcontext-simple's Unicode input and compose sequences.
+    gtk-im-context-simple's Unicode input and compose sequences.
     Alternatively remove the imsettings package to allow using
-    gtk-imcontext-simple but this will also remove all other
+    gtk-im-context-simple but this will also remove all other
     input methods from the system.
 * Result
-    With the above workarounds gtk-imcontext-simple can be used+    With the above workarounds gtk-imcontext-simple can be used.

Comment 19 Ryan Lerch 2010-09-17 04:53:06 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,18 +1 @@
-* Cause
+Using the im-chooser tool, XIM cannot be disabled as the default GTK immodule. Disabling input-methods using im-chooser and restarting the desktop session will still result in GTK applications using the XIM immodule. Consequently, using the Ctrl+Shift+U key combination to the directly input of Unicode characters from their hexidecimal code will not work. To work around this issue, use im-chooser to enable ibus. Enabling ibus permits gtk-im-context-simple's Unicode input and compose sequences to be used.-    Due to an oversight it is not possible to disable XIM
-    as the default GTK immodule from im-chooser.
-    Turning off input-methods in im-chooser and restarting the desktop
-    session still results in GTK applications using the XIM immodule
-    by default instead of gtk-im-context-simple.
-* Consequence
-    It is not possible to input Unicode characters directly by
-    hexidecimal code using Ctrl+Shift+U.  On the other hand
-    X locale compose sequences work correctly.
-* Workaround
-    Use im-chooser to turn on ibus, which supports
-    gtk-im-context-simple's Unicode input and compose sequences.
-    Alternatively remove the imsettings package to allow using
-    gtk-im-context-simple but this will also remove all other
-    input methods from the system.
-* Result
-    With the above workarounds gtk-imcontext-simple can be used.

Comment 23 errata-xmlrpc 2011-05-19 11:52:44 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0521.html


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