Bug 1150199

gnome-desktop3-3.10.2-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gnome-desktop3-3.10.2-3.fc20

(In reply to Fedora Update System from comment #1)
> gnome-desktop3-3.10.2-3.fc20 has been submitted as an update for Fedora 20.
> https://admin.fedoraproject.org/updates/gnome-desktop3-3.10.2-3.fc20

That works, the Russian legacy keyboard layout is listed in 
“gnome-control-center region” now.

I've found something strange.
In xawtv some hotkeys are defined, for example,
'a' toggles mute status.
If I use EN, that works.
If I use Р (aka rusle) - it still works, although 'a'
should became 'ф'.
If I use RU (aka XKB Russian legacy) - hotkey does not work.

Notably, I am not sure what is the correct behaviour.
Maybe the latinic hot key should not work in cyrillic mode?
But in any case, the difference between rusle and XKB
is very suspicious.

(In reply to Stas Sergeev from comment #3)
> If I use Р (aka rusle) - it still works, although 'a'
> should became 'ф'.
> If I use RU (aka XKB Russian legacy) - hotkey does not work.

This sounds like an ibus issue perhaps?

Probably better to report it separately.

(In reply to Jens Petersen from comment #4)
> (In reply to Stas Sergeev from comment #3)
> > If I use Р (aka rusle) - it still works, although 'a'
> > should became 'ф'.
> > If I use RU (aka XKB Russian legacy) - hotkey does not work.
> 
> This sounds like an ibus issue perhaps?
> 
> Probably better to report it separately.

Because 'a' does not exist in Russian keyboard. The shortcut key would be wrong.

(In reply to Stas Sergeev from comment #3)
> I've found something strange.
> In xawtv some hotkeys are defined, for example,
> 'a' toggles mute status.
> If I use EN, that works.
> If I use Р (aka rusle) - it still works, although 'a'
> should became 'ф'.
> If I use RU (aka XKB Russian legacy) - hotkey does not work.
> 
> Notably, I am not sure what is the correct behaviour.
> Maybe the latinic hot key should not work in cyrillic mode?
> But in any case, the difference between rusle and XKB
> is very suspicious.

No, that’s normal.

xawtv is neither a GTK nor a Qt program, but a plain X11 program.

X11 programs can use input methods like ibus only via XIM.

To use XIM, an X11 program has to call XSetLocaleModifiers("")
somewhere.

xawtv does not do that (Why should it? There is nothing to input 
in xawtv)

So if you try to use the rusle table with xawtv (or *any* other
ibus input method for that matter ...), the input method is
not switched on and xawtv just gets the key event.

When using the rusle table with ibus, that means you get the
key events of the keyboard layout used with rusle, which is
forced to be the us keyboard layout in case of rusle. Because of

    ### The Keyboard Layout used by this table.
    ### Set to "default" to accept any kind of layout
    KEYBOARD_LAYOUT = us

in the source of the rusle table.

So xawtv just gets the 'a' if you press the 'a' key
and for xawtv, 'a' means mute/unmute.

But if you use the Russian legacy XKB keyboard layout, that
key already gives a 'ф' which is ignored by xawtv.

You can see exactly the same with other X11 applications which do not
call XSetLocaleModifiers("").

Try it with 'xev', that shows you clearly that you get an 'a', not a 'ф'
in 'xev' no matter whether ibus-table with rusle is turned on or off.
Note that you cannot switch between direct input and table mode
(☐Р/☑Р) using the hotkey (Left Shift) either while 'xev', 'xawtv' (or
other X11 programs not supporting XIM) have focus. Because that hotkey
would be handled by ibus-table, i.e. the input method, but that
is not switched on in 'xev' and 'xawtv'.

Thanks, pretty clear.

(In reply to Mike FABIAN from comment #6)
> Note that you cannot switch between direct input and table mode
> (☐Р/☑Р) using the hotkey (Left Shift) either while 'xev', 'xawtv' (or
Indeed, and, quite spectacularly, it stays checked,
while it would be more appropriate to stay unchecked
in this case (I realize it is probably not possible
to change this).

There is something else is wrong too.
After I added both rusle and XKB ru, some
sequence of events (that involves switching and
typing) causes the firefox menus to stop working.
They appear just for a short moment and immediately
disappear, as if some key like ESC is being constantly
pressed.
I don't know how to reliably reproduce that yet,
but it happened many times, and the only cure
I've found is to close firefox.
Very annoying...

The effect is very similar to this:
https://bugs.launchpad.net/libdbusmenu-qt/+bug/1035755
but the conditions look entirely different.
Still they say there is something with event
timestamps, and I wonder if this can ring any bells...

gnome-desktop3-3.10.2-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.