Bug 616061
Summary: | can't disable gtk XIM to use gtk-im-context-simple | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Andrew Overholt <overholt> | |
Component: | imsettings | Assignee: | Jens Petersen <petersen> | |
Status: | CLOSED ERRATA | QA Contact: | QE Internationalization Bugs <qe-i18n-bugs> | |
Severity: | low | Docs Contact: | ||
Priority: | low | |||
Version: | 6.0 | CC: | eng-i18n-bugs, llim, myllynen, petersen, rlerch, rstrode | |
Target Milestone: | rc | Keywords: | Reopened | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
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.
|
Story Points: | --- | |
Clone Of: | ||||
: | 623931 (view as bug list) | Environment: | ||
Last Closed: | 2011-05-19 11:52:44 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | 505100 | |||
Bug Blocks: | 623931, 659134 |
Description
Andrew Overholt
2010-07-19 14:52:47 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. ** 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. 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? > 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. 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. Any change should be made first in Fedora. (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? I believe current behaviour is at least consistent across X, GTK, and Qt. Sure. so what do you suggest to get this fixed in imsettings? (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... (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. 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. There an update now in testing for F14: https://admin.fedoraproject.org/updates/imsettings-0.108.1-2.fc14 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 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. 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. 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 |