Bug 623931
Summary: | can't enable gtk-im-context-simple for unicode Ctrl-Shift-u input | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> |
Component: | imsettings | Assignee: | Jens Petersen <petersen> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | eng-i18n-bugs, i18n-bugs, john, kevin, llim, mclasen, myllynen, overholt, petersen, rstrode, tagoh |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | imsettings-0.108.1-2.fc13 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | 616061 | Environment: | |
Last Closed: | 2010-12-09 06:32:26 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, 616061 | ||
Bug Blocks: |
Description
Jens Petersen
2010-08-13 07:34:29 UTC
imsettings-0.108.1-2.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/imsettings-0.108.1-2.fc14 $ git clone git://anongit.freedesktop.org/xorg/lib/libX11 $ cd libX11/nls $ $ for i in *; do if [ -d $i -a -s $i/Compose.pre ]; then if ! grep -q "This file currently has no entries." $i/Compose.pre ; then echo $i; fi; fi; done | grep UTF am_ET.UTF-8 el_GR.UTF-8 en_US.UTF-8 fi_FI.UTF-8 pt_BR.UTF-8 ru_RU.UTF-8 $ Those seem to be the only UTF-8 locales with actual compose sequences. pt_BR and fi_FI are already covered. I am pretty user regular en_US users don't need it by default. am_ET was for OLPC and can be handled otherwise I think. That leaves just ru_RU and el_GR, which can be added later if necessary. So in conclusion special-casing X compose seems to make good sense for now. Though Marko Myllynen told me about http://www.csc.fi/english/pages/meek which might lead to more compose usage in the EU in the future perhaps. imsettings-0.108.1-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/imsettings-0.108.1-2.fc13 imsettings-0.108.1-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update imsettings'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/imsettings-0.108.1-2.fc13 I added am_ET, el_GR, and ru_RU also to imsettings/master. imsettings-0.108.1-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. imsettings-0.108.1-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. IMHO this "bugfix" is a regression, you've now made GTK+ use its own nonstandard and incomplete (no support for compose sequences!) input handling by default instead of using the shared input platform everything in Fedora uses. And no, we have no plans whatsoever to change Qt not to use XIM, it would have no advantage anyway, that Ctrl+Shift+u combo is a feature specific to GTK+'s input implementation, I don't think Qt implements that. By the way: * How do I set GTK+ back to using XIM after this "fix"? * Is there a way we can default GTK+ to XIM input for KDE users, without breaking other things such as IBus support? I really don't see why a KDE user would want GTK+ apps to behave differently from the rest of his KDE desktop. PS: In the past, when the default was "simple", I always thought XChat was broken for not supporting Compose. Then I noticed it's all GTK+ apps. And then I found out that it was a GTK+ "feature", a.k.a. bug 505100. I was happy that this was finally fixed. I really don't see why we now reverted that bugfix just to support a GTK+-only hack which is implemented completely at the wrong point of the input stack. (Something like Ctrl+Shift+u needs to be implemented in an input method framework, so all apps benefit from it, not at toolkit level.) PPS: Actually #505100 is not the correct bug reference. But GTK+ not supporting Compose is a bug, which you just reintroduced. (Sorry for the quadruple post, always more stuff to add.) > own nonstandard and incomplete (no support for compose sequences!)
not sure what you are talking about. GTK's builtin input method supports compose sequences alright.
GTK supports the compose key fine. Sometimes which sequences it supports lags a bit, but overall it works. If i type <compose> + - + > i get → <compose> + < + 3 i get ♥ <compose> + ' + a i get á etc You can force gtk apps to use a different im module by setting the "Gtk/IMModule" X setting in your settings daemon app. Although, there's no guarantee the user will have gtk2-immodule-xim installed. > GTK's builtin input method supports compose sequences alright. Please note that GTK's builtins conflicts with some compose maps like fi_FI (which is actually needed to comply with a national standard). One example from https://bugzilla.redhat.com/show_bug.cgi?id=505100#c71: dead_acute + space produces ' if using en_US.UTF-8/Compose (or GTK builtins) dead_acute + space produces ´ if using fi_FI.UTF-8/Compose The above comment provides some additional details. Thanks. Well it is clear that GTK compose rules are different from the more standard compose sequences supported by libX11. The main improvement of this update is that it is now at least possible to turn off XIM for GTK which was not possible before. Perhaps we should just default to XIM compose for everyone except en_* then? (In reply to comment #9) > * How do I set GTK+ back to using XIM after this "fix"? In im-chooser turn on IM and select X compose. > * Is there a way we can default GTK+ to XIM input for KDE users, without > breaking other things such as IBus support? I really don't see why a KDE user > would want GTK+ apps to behave differently from the rest of his KDE desktop. I think we should try to agree to do the same across all desktops otherwise it impacts QA testing complexity and UX consistency. How about my suggestion in the previous comment? (In reply to comment #10) > PS: In the past, when the default was "simple", I always thought XChat was > broken for not supporting Compose. Then I noticed it's all GTK+ apps. And then > I found out that it was a GTK+ "feature", a.k.a. bug 505100. I was happy that > this was finally fixed. I really don't see why we now reverted that bugfix just > to support a GTK+-only hack which is implemented completely at the wrong point > of the input stack. (Something like Ctrl+Shift+u needs to be implemented in an > input method framework, so all apps benefit from it, not at toolkit level.) Thanks for speaking up anyway - glad some people liked the default gtk XIM in F13. Kevin: BTW what locale do you normally use? > In im-chooser turn on IM and select X compose. I have no im-chooser running on my KDE system in the first place! It's a GNOME tool which does not autostart in KDE. I ended up hand-editing /etc/X11/xinit/xinput.d/none.conf (which is probably a hack, is that file even marked %config?) for now. > Perhaps we should just default to XIM compose for everyone except en_* > then? IMHO it should just be everyone, including en_*. > Kevin: BTW what locale do you normally use? de_AT.UTF-8 with de keyboard layout and compose on Shift+AltGr enabled in the xkb settings. (I miss the time that that was the default, too. It got changed because some newbies can't deal with the fact that Shift+AltGr is not the same thing as AltGr+Shift, i.e. ordering matters. See the discussion in bug 193922. I'm still unhappy about that change, too.) (But at least there's a way to set the xkb settings from KDE's System Settings. There's no such thing for imsettings settings.) (In reply to comment #18) > > In im-chooser turn on IM and select X compose. > > I have no im-chooser running on my KDE system in the first place! It's a GNOME > tool which does not autostart in KDE. No it isn't - it is a desktop tool installed by default in Fedora. Anyway this bug is about GTK apps. > I ended up hand-editing /etc/X11/xinit/xinput.d/none.conf (which is probably a > hack, is that file even marked %config?) for now. It is not really a user-configuration file. You should override with "~/.xinputrc". (In reply to comment #15) > Perhaps we should just default to XIM compose for everyone except en_* > then? No. (In reply to comment #18) > > In im-chooser turn on IM and select X compose. > > I have no im-chooser running on my KDE system in the first place! It's a GNOME > tool which does not autostart in KDE. > The im-chooser is not a GNOME tool. I don't see any consensus emerging so I plan to take this discussion to the mailing lists. Just for the record, ibus also has some compose support (might not be working currently in 1.3.7 though). I am surprised more country keyboard layouts don't provide a Compose key by default. AFAICT only standard gb, ie, and fi layouts do that. (Many countries use ISO_Level_3_Shift though instead.) It's not really an "instead". If you enable Shift+AltGr compose on layouts which use ISO_Level_3_Shift, you'll have Shift+AltGr (in this order) = Compose and AltGr+Shift (in that order) = ISO_Level_3_Shift. I am going to look at the various compose rules provided by X, gtk, and ibus to get a better idea how they compare. (Compose should be working again in ibus-1.3.7-3.fc14 btw.) Kevin, do you have some examples of where gtkimcontextsimple compose behaves differently from how you expect it? That would be useful data. According to gtk/gtkimcontextsimpleseqs.h gtk it ought to support most compose sequences in libX11 and was last updated 2008. http://git.gnome.org/browse/gtk+/tree/gtk/gtkimcontextsimpleseqs.h (In reply to comment #10) > of the input stack. (Something like Ctrl+Shift+u needs to be implemented in an > input method framework, so all apps benefit from it, not at toolkit level.) (In reply to comment #25) > I am surprised more country keyboard layouts don't provide > a Compose key by default. AFAICT only standard gb, ie, and fi layouts >.do that. (Many countries use ISO_Level_3_Shift though instead.) So where’s the place to discuss such things? I’m a hefty user of C+S+u even with a compose-aware keymap, and would dislike it not returning. (In reply to comment #30) > (In reply to comment #10) > > (Something like Ctrl+Shift+u needs to be implemented in an > > input method framework, so all apps benefit from it, not at toolkit level.) ibus-gtk already does. Perhaps ibus-qt could do it too. I still think that compose and input methods are more natural input systems than direct Unicode though. > So where’s the place to discuss such things? I’m a hefty user of C+S+u even > with a compose-aware keymap, and would dislike it not returning. It is already back as of comment 6. What are you missing? :) Anyone have any more input on Gtk vs X compose rules? I am planning to close the bug after a week. It would probably be better to open a new bug anyway for any further required changes. |