Bug 193922

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.