Description of problem: Previous releases of Xorg correctly had compose enabled for a UK keymap. This is neccessary to type in words like naive, cafe correctly in British English. It is now no longer possible to type English correctly using a UK keymap. This urgently needs reverting, and certainly before RHEL5 develops the same flaw.
Console mode compose is btw working correctly, only X is broken.
Please file a bug report in upstream bugzilla at http://bugs.freedesktop.org in the 'xkbdesc' (xkeyboard-config) component. Upstream is quite responsive, and we will track the issue there. Once a fix is available, we'll include it in an xkeyboard-config update. Thanks in advance.
Done.
Helps to have an upstream reference...
Created attachment 134203 [details] Add Compose semantics to right Alt when that's ISO_Level3_Shift
Comment on attachment 134203 [details] Add Compose semantics to right Alt when that's ISO_Level3_Shift It's easy enough to fix this problem...
Great, can we get this into FC6t3 as FC6 is also broken
Fixed in xkeyboard-config-0.8-3.
What about FC5? And the answer to the upstream question is that Shift+RAlt != RAlt+Shift.
Confirm the fix works - thanks a lot.
The "fix" seriously breaks Polish keyboard in FC6. In Polish symbols file there's a comment that there was a level3(ralt_switch_multikey) version of level3 with Multi_key as Shift-AltGr, while level3(ralt_switch) was only ISO_Level3_Shift under AltGr (even shifted). I propose a fix which adds real level3(ralt_switch_multikey) in xkeyboard-config-0.8-composify-ralt.patch and use that instead of 'include "level3(ralt_switch)"' in xkb/symbols/gb (this is the English keyboard Alan is using, right?). I'm attaching my vision of xkeyboard-config-0.8-composify-ralt.patch doing things the way which I just described. It works for me and the gb layout includes Multi_key (and pl doesn't). I don't know how to use that key, though. However, I can type naïve using altgr+[, i and café using altgr+;, e :) My bug about Polish keyboard is bug #214453. Can you reopen this one and make mine a duplicate?
Created attachment 140701 [details] Better version of xkeyboard-config-0.8-composify-ralt.patch At least better for Polish users.
Oh, and it seems to be fixed in the same fashion in Xorg [I haven't discovered external reference to bugs.freedesktop.org at the end of this page until now... :)] Can we get an update of xkeyboard-config in FC6 to upstream cvs/svn, then? There's just too much localization problems for Polish to even show FC6 to friends ;)
*** Bug 214453 has been marked as a duplicate of this bug. ***
Differences between CVS/devel version of the patch and two other available versions: 1) we have attached in CVS/devel (as of now) version shown here as the attachment 134203 [details], which is the shortest one. 2) freedesktop.org bug no. 7674 and attachment 140701 [details] of this bug are longer versions of the same Diff between all three patches are applied.
Created attachment 141075 [details] Differences between the patch in CVS/devel and the attachment 140701 [details]
Created attachment 141076 [details] Differences between our CVS/devel patch and the one in freedesktop bugzilla
Created attachment 141077 [details] Differences between upstream bug and our attachment 140701 [details]
Created attachment 141079 [details] upstream patch
Ping? And while I'm at it, the correct component field here is "xkeyboard-config".
This was fixed in Rawhide (check bug 237369) by updating xkeyboard-config to 1.0. Maybe you could reconsider updating FC6 and F7 before F8 comes out? This has the potential to fix "around 70 bugs" other than regression introduced by "fix" for this bug.
Fedora Core 6 is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora 7, 8, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. [This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or Gecko. If you see any other reason, why this bug shouldn't be closed, please, comment on it here.]
UK seems fine, no ideal about Polish
It's fixed in F8, but F7 had an older (broken) xkeyboard-config the last time I checked. F7 is still supported, but this bug can be safely closed as fixed in current release (and affected F7 users can upgrade the single package if they're not ready for F8).
OK, switching this bug to F7, and if it won't get help there, it will be closed when F7 is EOLed.
The "better" patch regresses the compose key to no longer work in many layouts, e.g. de (German). It worked in F7, it's broken again in F8. Changing include "level3(ralt_switch)" to include "level3(ralt_switch_multikey)" in /usr/share/X11/xkb/symbols/de fixed it. I think these should either all use ralt_switch_multikey or the original patch to change ralt_switch should be restored. The "bug 214453" is _not_ a bug, it's exactly the intended behavior, Shift+AltGr is not the same as AltGr+Shift, this is a feature!
IMHO, at least us_intl and the Western European layouts (de, fr, it, ...) should default to ralt_switch_multikey. Sure, these layouts have accent keys, but compose allows conveniently entering characters like œ or ±. There's no œ in the default French layout for historical reasons, so compose is actually required to enter correct French.
1. I don't know about KDE, but in GNOME it's as easy as 5 clicks to enable the Multi Key feature in languages which normally use Shift-AltGr as something other. 2. If something is changing a keyboard layout used by millions of people for more than 20 years, breaking 8 keys and introducing a new one, with no obvious use for any of the users... it simply has to be a bug. And I don't understand, what makes you decide what is best for a Polish keyboard. If German or French are broken, that's not my or Fedoras fault - it was changed upstream.
Kristian, I will have to investigate it more (whether the bug is in Gnome or in Xorg), but currently I just could report that with cs_CZ keyboard layout, I have no Compose key at all (when set my CapsLock as Compose with gnome-keyboard-properties).
Any opinions about that ralt_switch_multikey issue? As I said in comment #27, I think at least the us_intl layout and the Western European layouts should default to it, at the very least the default French layout which currently doesn't allow entering correct French. (Yes, the œ character is often not used, but AFAIK that's because of the keyboard layout not allowing to enter it, not the opposite.)
(In reply to comment #30) > Any opinions about that ralt_switch_multikey issue? a) please don't hijack this bug -- this is new issue which is not the same as this bug, b) I don't think it is a good idea -- there are many computers (think notebooks) which don't have ralt. But yes, having default (and working!!!) Compose would be nice.
I wouldn't call it a different issue. Some history there: Compose on Shift+RAlt used to be enabled for most keyboard layouts, then it got disabled, then it got reenabled (using the patch from comment #5) for all the layouts it used to be enabled for and then suddenly the change was made UK-only as per comment #12 (to fix an issue specific to the Polish layout, where AltGr+Shift being different from Shift+AltGr didn't match user expectations, even if it was fully intentional, because Polish uses AltGr+Shift+letter combinations a lot) and that's where we are now. Now if you want, I can clone this and change the subject to "Compose now incorrectly disabled in all non-UK keymaps"...
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Kevin: I talked to Sergey V. Udaltsov (xkeyboard-config maintainer) about this change and he is not happy with enabling multikey for all these languages (I proposed us_intl + most western european). The XKBOption lvl3:ralt_switch_multikey is readily available if you need it though.
Closing this bugs. The original problem has been fixed, if there are outstanding issues with other keyboard layouts, please file a separate bug for them.