Keyboard shortcuts (hotkeys) not functional in some cases in non-latin keyboard layouts

[Misha Bazanov]

Keyboard shortcuts are key combinations like Alt+F (usually opens the File menu) and Ctrl+O (usually opens the File→Open... dialog box).

There is an issue with non-latin keyboard layouts that the keys under F or O (for Alt+F and Ctrl+O respectively) would correspond to some other character.
What should happen then? There is some smart functionality (at least in the GTK+ library) that when we press a shortcut, it will try to make Alt+F or Ctrl+O work, even if the active keyboard layout is not English.

For this smart functionality to work, it requires us to have as first keyboard layout the English (en) layout. Then, GTK+ will be able to
check whether the shortcut makes sense for English, and if so, will run it.
All that even if the active layout is Greek or Russian or something else.

This report has over 300 comments and these comments include all sort of corner cases that indeed shortcuts do not work. In general, shortcuts work,
but in specific cases there are issues that need to be fixed.

What we need to do, is collect those corner cases and create new separate reports.

Here are the corner cases:

1. In Dash (in Unity 7), shortcuts like Super+S/W work (for example, Greek, Russian), but they do not work for Super+A/F/M/C/V.
Report: <not reported yet>

2. Java GUI applications on Linux do not support shortcuts in non-latin languages. This is an issue with Java and should be reported there.
Java GUI apps are not included in any of the Ubuntu ISOs.
Report: <not reported yet>

3. Shortcuts that use Ctrl on LibreOffice work for several languages (like Greek, Russian), but has been reported not to work on Hebrew.
This should be a separate bug report specific to Hebrew and other languages affected in the same way.
Report: <not reported yet>

[Leonid (leonid-redhat-bugs)]

Description of problem:

If Russian xkb layout is active, it's impossible to use keyboard shortcuts like
ctrl-c (copy), ctrl-v (paste) etc. It makes this build of openoffice absolutely
unusable for somebody who was using other office (microsoft) or other build of
openoffice.org for a long time.

Version-Release number of selected component (if applicable):

1.9.87-2

How reproducible:

always

Steps to Reproduce:
1. Start gnome keyboard properties and select Russian layout
2. Start openoffice writer and verify that keyboard produces kyrillic characters.
3. Try to use ctrl-c and ctrl-v for copy and paste text

Actual results:

Nothing will happen

Expected results:

Ctrl-c and ctrl-v should work for copy and paste

Additional info:

This bug was not reproduced with openoffice.org build from
http://www.openoffice.org.

[Caolan (caolan-redhat-bugs)]

*** Bug 147092 has been marked as a duplicate of this bug. ***

[Leonid (leonid-redhat-bugs)]

Looks like it's not openoffice.org bug, because it works great in KDE. It's
gnome bug, and it's hanging on gnome bugzilla for a long time, see
http://bugzilla.gnome.org/show_bug.cgi?id=103331

no idea what component shoud be chosen :(

[Nadvorny (nadvorny)]

Hotkeys are language dependent and work in English language only.
While writing in any other language i.e. any Cyrillic, it's impossible to use hotkeys, they just don't do anything. Switching to English input language enable hotkeys once again.

This is very frustrating as user needs to switch language to save document, to make it bold, or italic, etc.

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

[Nadvorny (nadvorny)]

Adding more info.

Verified and reproduced on: 3.4.3, 3.4.4, 3.5.0.beta1 and 3.5.0.beta2.
Mac OS X specific.

Steps to reproduce:
1. Launch Writer.
2. Change language to Russian.
3. Press Cmd+B to change font weight to bold.

Error: Font weight does not get changed. System error sound is played instead.

Expected: Font weight changed to bold.

Note that some other system hotkeys work as expected. I.e. Cmd+S to save, or Cmd+O to open document still work regardless of input language. Other critical key combinations that don't work: Cmd+I, Cmd+U and so on, all text manipulation hotkeys are English-only. One may assume that hotkeys don't work correctly in text area, but do work for UI.

Workaround 1: Click toolbar button to apply corresponding style.
Workaround 2: Change language to English, press desired hotkey, then switch language back to russian.

The issue is critical, as it make text editor very slow for keyboard-only typing.

[Bitigchi (bitigchi)]

*** Bug 57290 has been marked as a duplicate of this bug. ***

[Infusiastic (infusiastic)]

Reproduced in 6.6.4.3 on Mac OS X 10.7.5.

[Ashkan Valizadeh (valizadeh-ashkan)]

I also confirm this in LibreOffice 3.6.3, and it is really annoying to change keyboard to En, only to use a shortcut and then change it back to whatever it was and then continue.

I use Fedora, but this problem was not occurred in Fedora 17 or Windows, as they both use a different keyboard handling method than Fedora 18 (http://fedoraproject.org/wiki/Common_F18_bugs#Installer_does_not_automatically_set_up_multiple_keyboard_layouts_and_switch_command). But now in Fedora 18, lots of program are affected by this change.

Applications such as gedit, nautilus, fileroller (Archive Manager) which are parts of gnome act like before, which means there is no difference which keyboard layout is currently active, the keyboard shortcuts work OK. But other applications usually is not the same, like LibreOffice, Zim, Blender, ... .

So, I don't know where the problem is, but as (let say native) gnome applications are working fine, so there must be a way to solve this problem with others.

[Ashkan Valizadeh (valizadeh-ashkan)]

The problem still exist in LibreOffice 3.6.5.2 in Fedora 18.
I realy dont know why no developer really pay attention to fix this problem.
It may looks like that it is not important but it really affected the productivity of LibreOffice for non-Latin users.

[Ashkan Valizadeh (valizadeh-ashkan)]

Today I downloaded LibreOffice 4.0.0.3 from the official website and the problem still is there.

I also install all available desktops in Fedora 18 repo and test LibreOffice against theme to check whether the problem of keyboard shortcuts in non-latin layout is steal exist or not:

KDE: No problem
MATE: No problem
XFCE: No problem

LXDE: Problem exist
Cinnamon: Problem exist

All the three first desktops still use the same keyboard handling as they used to be, but Cinnamon is based on gnome 3 and inherits its problems, and I have no idea about LXDE problem.

I really hope someone at last pay some attention to this problem and attempt to fix it.

[Ashkan Valizadeh (valizadeh-ashkan)]

Today I also use the JHBuild tool on Fedora 18 to compile the Gnome 3.7.5 from their external module sets which contain the released tarbals. (http://ftp.gnome.org/pub/GNOME/teams/releng/3.7.5)

Well, not too surprising, the problem is still exist using Gnome 3.7.5 and LibreOffice 4.0.0.3. This means that LibreOffice needs to make some changes in its keyboard shortcut handling, as it's likely that gnome is not and will not follow its old keyboard management.

I am really hoping some developer at least look at this bug and put some information or notes here.

[Ashkan Valizadeh (valizadeh-ashkan)]

Here is how some other big open source products fix this issue:

Mozilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=61190
https://bugzilla.mozilla.org/attachment.cgi?id=307428&action=diff

Eclipse:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=61190

According to this page Chromium fix this in version 3.0.196 afterwards, so it might have something helpful:
http://code.google.com/p/chromium/issues/detail?id=16806

And also a patch for Gnome which I don't know how to make it work:
https://bugzilla.gnome.org/show_bug.cgi?id=685676
https://bugzilla.gnome.org/attachment.cgi?id=230597

[Ashkan Valizadeh (valizadeh-ashkan)]

Sorry in last comment I sent the Eclipse link in Mozilla part.

[Bitigchi (bitigchi)]

*** Bug 62330 has been marked as a duplicate of this bug. ***

[Defking (defking)]

Confirm this bug still exists in LibreOffice 4.0.2.2.
Very annoying. The only workaround is to use other apps, like gedit for example. All hotkeys work great in any language there.

Using ArchLinux with latest GNOME-Shell 3.8 from gnome-testing repo.

[Signup-r (signup-r)]

I can confirm the bug exists in LibreOffice 4.0.2.2 on MacOS X 10.8.3. It's not a Linux-specific bug.

[Abdalrahim G. Fakhouri (abdilra7eem)]

I can not confirm the bug on 4.1.0.0beta1 on Ubuntu.
I selected a text, and pressed ctrl+b to make it bold.
I tested with the input configured as: English, Arabic, Turkish & French
results: normal behavior.

[Abdalrahim G. Fakhouri (abdilra7eem)]

P.S.: I use cinnamon

[Sina Momken (digitsm)]

*** Bug 63763 has been marked as a duplicate of this bug. ***

[Sina Momken (digitsm)]

I have the same problem. When my keyboard layout is in a non-English language (in my case Fa) most shortcuts don't work (e.g. Ctrl+C, Ctrl+S, customized LO‌ shortcuts).

My system: Linux Mint Debian Edition Update Pack 6, XFCE 4.8, LibreOffice 3.5.4.2, both libreoffice-gnome and libreoffice-gtk packages installed.

(In reply to comment #5)
> ...
> Applications such as gedit, nautilus, fileroller (Archive Manager) which are
> parts of gnome act like before, which means there is no difference which
> keyboard layout is currently active, the keyboard shortcuts work OK. But
> other applications usually is not the same, like LibreOffice, Zim, Blender,
> ... .
Also in my case, as AshkanV mentioned in comment #5, many other applications work just fine. I'm in XFCE but I also have Gnome, KDE and Mate installed. And text editors of all of these DEs work correctly.

[Sina Momken (digitsm)]

In the both links below they blame packages libreoffice-gtk or libreoffice-gnome.
http://en.libreofficeforum.org/node/1586#comment-26769
http://ubuntuforums.org/showthread.php?t=1986133

Someone also suggested resetting LO user profile in duplicate Bug 63763:
https://wiki.documentfoundation.org/UserProfile

However as mentioned in comment #13 this bug could be reproduced in LibreOffice 4.0.2.2 on MacOS X 10.8.3, which complicates the situation.

[pva (pva)]

Sina, resetting profile does not help. Also this bug is reproducible in 4.1.0.4.

[Yotam Benshalom (benshalom)]

This bug is reproducible on gnome-shell in ubuntu 13.10, which handles now keyboard events with the new gnome-settings-daemon instead of directing them to X. It is indeed a crucial issue for all of us who happen to work with a non-latin language.

[Alex (alex-redhat-bugs)]

Description of problem:
If Russian xkb layout is active, it's impossible to use keyboard shortcuts in non-gtk programs.

Version-Release number of selected component (if applicable):
Gnome Shell - 3.8.4-2.fc19
GTK: gtk3 - 3.8.4-1.fc19

How reproducible:
always

Steps to Reproduce:
0. Login with gnome-shell
1. Start blender
2. Switch keyboard layout to russian
3. Press hotkey 's' to resize default cube

Actual results:
Nothing will happen

Expected results:
Resize default cube

Additional info:

Hotkeys in russian layout works with gtk-programs, like:
Geany, Gedit, Gnome Terminal, Transmission.

And don't work with any non-gtk programs, like:
LibreOffice, blender, psi, QBittorrent.

It's a gnome problem. If login in KDE - then hotkeys in russian layout works fine.

[Brandon Schaefer (brandontschaefer)]

Testing in Firefox with Afghani, ctrl+t for new tab works. Though ctrl+alt+t does now...which would is possibly under gnome-compatibilty in compiz.... but one would think things should still work? As im not sure what the new layout changer did that would cause it to stop working. Unless it hadn't worked before...as we should still be getting the same events as before through compiz/unity. A new keyboard layout changer shouldn't change the type of events we get hmmm. I need to test if Ctrl+Alt+t worked before the new layouts...

[Misha Bazanov (bmw-)]

Are you testing Ubuntu 13.10? May be i'm wrong and this issue it is not related to layout changer.

[Brandon Schaefer (brandontschaefer)]

Yup, on 13.10. My ctrl+t know doesn't work. Sooo i must have messed up testing it :). So yes there is a problem there.

Really im just wondering what use to happen, if this is a regression. As I see 3 cases, and 2 different ways to handle this.

1) You are using a standard qwerty latin keyboard with all the keys in the correct spot.
2) You are using a different layout where they keys (such as 't') may be in different locations.
3) You are using a language where such a key does not exists (such as 't').

The two ways to possibly handle this, as in case 1 there is no need to change how we handle it.

If case 2, use the new location of the key if it has moved.
If case 3, use the keycode of the key it self when no such key exists.

Not entirely sure what the approach should be and would like to discuss this a bit more before heading down an implementation.

[Misha Bazanov (bmw-)]

I do not know much about non-english layouts with Latin character set. If they all contain a full set of English letters - move key to new location seems logical. Have no idea what DVORAK layout users think about it. Hotkeys like ctrl+x ctrl+c ctrl+v looks little absurdly, when they scattered on keyboard.

As russian user, i'm using cyrillic character set and expect hot keys use same key regardless of the layout (case 3).

[Brandon Schaefer (brandontschaefer)]

Stephen and I looked into this. Turns out you're correct about the new keyboard layout changer did cause this bug to resurface. Though the reason, was there was a bug in the old keyboard layout changer. It was using the first keyboard layout you had (such as english) for the shortcuts.

So a bug was fixed in the keyboard changer that was fixing this issue...fun. So there really was no correct solution implemented for this. (Though there does appear to be some shortcuts that do still work regardless. ex: super+w/super+s).

We are going to have to discuss this and aim to land a fix in for 14.04 as there is no time for 13.10 :(.

Thank you very much for bringing this problem to our attention!

[George Christofis (geochr)]

@Brandon Schaefer (brandontschaefer)
[qoute="Brandon Schaefer"]We are going to have to discuss this and aim to land a fix in for 14.04 as there is no time for 13.10 :(.[/qupte]
Is that the official answer ?
With simple words you are saying us that no one can use the 13.10 as properly if works with his native language (non English)???

Is it possible to release 13.10 with a bug that affects millions users on their native language?
In my opinion, If this bug exists after release, then the 13.10 will be a non-handy version for many users.

Am i wrong, is there something that i misunderstanding?

[Simos Xenitellis  (simosx)]

I am using 13.10 (latest updates) and I have configured the layouts US English, Greek, Russian.

I started "gedit" (core GTK+ app) and I switch keyboard layout to Greek.

1. I typed some text in Greek. Then, pressed Ctrl+A (Select All) but nothing happened. Instead, the whole text should have been selected.
In the Greek keyboard layout, the Greek A is on the same physical key as the Latin A.

2. I pressed Alt+F (Open the File menu). Nothing happened.

GTK+ should have handled correctly both of these cases as it has code to handle the multiple-layout issue.
I tried to unset 'GTK_MODULES' (has a value of 'unity-gtk-module'), but I did not get back the old behavior.
I could not find a workaround for these critical issues.

[Simos Xenitellis  (simosx)]

A workaround to get shortcuts in non-Latin scripts to work again is to kill any IBus processes.

I killed

/usr/bin/ibus-daemon --replace --xim --panel disable
/usr/lib/ibus/ibus-dconf
/usr/lib/ibus/ibus-x11 --kill-daemon
/usr/lib/ibus/ibus-engine-simple

and then I could "Select All", or start "Alt+F" to get the File menu.

Thus, IBus is interfering with GTK+ apps, even if for those apps the default GTK+ IM is active.

[Stephen M. Webb (bregma)]

Turns out the new keyboard indicator always starts ibus even when the system is configured to never run it, and even then ends up starting it with the wrong arguments.

[N1ck 7h0m4d4k15 (nicktux)]

I tested the /etc/default/im-config with several inputs (xim, none), but ibus is always there. Up and running.

I presume @Stephen M. Webb has right.

[Stephen M. Webb (bregma)]

The downside to just killing ibus-daemon is that every time you change your keyboard layout it restarts the daemon.

[N1ck 7h0m4d4k15 (nicktux)]

Yeap, just figured out.

This daemon is strong enough to resurrected himself :P

So comment #11 IS NOT A WORKAROUND. (I will hide it, so people not get confused). You have to kill ibus-daemon every time you change the layout.

Also I tried to disable it completely , then is not even start , through the following command

    gsettings set org.gnome.settings-daemon.plugins.keyboard active false

but then, shortcuts still not working.

This is strange enough for me (I'm not a developer) as it seems the shortcuts work only if you leave the ibus-daemon to be started and then kill it.

[William Hua (attente)]

I just tested this, I don't believe IBus is the culprit here. Killing IBus with another keyboard layout selected (I used Arabic) did not fix the hotkey problem. My guess is that this is in g-s-d, but I'm still looking into it.

[Stephen M. Webb (bregma)]

See https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1228422 for many quality comments describing the problems and side effects of running ibus-daemon when it is explicitly configured not to run.

[Lars Karlitski (larsu)]

I don't understand this. I'm running a German keyboard (Y and Z keys are swapped). Ctrl+Z has always been mapped to the physical Z key on my keyboard. It sounds like this bug is about changing that?

[Stephen M. Webb (bregma)]

@Lars

A Greek keyboard does not have a physical Z key, nether does an Arabic or Hebrew keyboard. There are different requirements for Latin and non-Latin keyboards, and different requirements again for IMs like the various Indic or CJK entry systems. That's why it's definitely wrong to force ibus to run when it's explicitly configured not to.

[Simos Xenitellis  (simosx)]

@Stephen: In Greek, the Z key happens to be on the same physical key as Z
on the US English/British physical key (Qwerty).

@Lars: GTK+ has code in
https://git.gnome.org/browse/gtk+/tree/gtk/gtkkeyhash.c so that when you
press Ctrl+A (where A is the Greek A), it will search what was supposed to
have been pressed if the first group (let's say 'keyboard layout', commonly
US English) was active. Thus, Ctrl+A (Greek Alpha) works with the GTK+ IM.

There is an issue if you happen to have two Latin keyboard layouts, such as
US English + German. Such a difficult situation is discussed at
https://bugzilla.gnome.org/show_bug.cgi?id=162726.

I think the goal for 13.10 should definitely be to get the GTK+ IM
functionality working again.

On Tue, Sep 24, 2013 at 11:34 PM, Stephen M. Webb <
<email address hidden>> wrote:

> @Lars
>
> A Greek keyboard does not have a physical Z key, nether does an Arabic
> or Hebrew keyboard. There are different requirements for Latin and
> non-Latin keyboards, and different requirements again for IMs like the
> various Indic or CJK entry systems. That's why it's definitely wrong to
> force ibus to run when it's explicitly configured not to.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout
>
> Status in Indicator keyboard:
> Triaged
> Status in Unity:
> Invalid
> Status in “indicator-keyboard” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> Invalid
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/indicator-keyboard/+bug/1226962/+subscriptions
>

--
CONFIDENTIALITY This e-mail and any attachments are confidential and may
also be privileged. If you are not the named recipient, please notify the
sender immediately and do not disclose the contents to another person, use
it for any purpose, or store or copy the information in any medium.

[Yotam Benshalom (benshalom)]

Still exists in LibreOffice 4.1.2.2.

[Filippos Kolyvas (fkol-k4)]

@ Dmitry, that's great news!
Is there some action that could be taken to achieve that, or will it be fixed by a future update?
On the second case, do we have a rough estimation on the arrival time of this fix?

[Misha Bazanov (bmw-)]

@Filippos it is just about project to witch bug is assigned.

[Simos Xenitellis  (simosx)]

@Misha: So you are saying that the bug still exists, it is not a Unity bug, but solely an "indicator keyboard" bug.

[Artyom Kazak (artyom-kazak)]

Shortcuts work when I’m using standard Russian layout, don’t work when I’m using my own custom layout; everything used to work flawlessly in 13.04.

[Simos Xenitellis  (simosx)]

@Artyom: The issue is with Ubuntu 13.10 which has specific new changes when switching layouts.
My layouts are EN/GR/RU, and while RU is active, the shortcuts do not work. I tested with Ctrl+A (Select All).
Do note that I check with 'gedit' (core GTK+ app). Some other apps like Chromium have specific changes and are unaffected.

[Yotam Benshalom (benshalom)]

Still exists in 4.1.2.3.

[Dmitry Shachnev (mitya57)]

I have uploaded gnome-settings-daemon with William's patch applied to ppa:mitya57/ppa, please test and give your feedback before it is uploaded to archive.

[Filippos Kolyvas (fkol-k4)]

Thanks Dmitry, i added the ppa, upgraded, rebooted and here are the results:

After upgrading, i cannot change layout using the shortcut, change is only possible with the mouse, so every layout change on following test is made using the mouse on the keyboard indicator:

Gedit (gtk core app): Hotkeys (copy, paste, print) are working on Greek layout.
Kate (KDE app): Hotkeys are not working on Greek layout.
LibreOffice: Hotkeys are not working on Greek layout.
Mozilla Firefox: Hotkeys are not working on Greek layout.
Chromium Browser - Google Chrome: Hotkeys are working on Greek layout.
Global shortcuts are probably working, for example ctrl+alt+T (gnome-terminal) shortcut works, super key +S works too (i haven't tested more shortcuts).

Hope that it's going to help.

[Dmitry Shachnev (mitya57)]

@Filippos: layout switching not working is a different issue, tracked in
bug 1218322. I hope William will look at it soon.
On Oct 6, 2013 6:00 PM, "Filippos Kolyvas" <email address hidden>
wrote:

> Thanks Dmitry, i added the ppa, upgraded, rebooted and here are the
> results:
>
> After upgrading, i cannot change layout using the shortcut, change is
> only possible with the mouse, so every layout change on following test
> is made using the mouse on the keyboard indicator:
>
> Gedit (gtk core app): Hotkeys (copy, paste, print) are working on Greek
> layout.
> Kate (KDE app): Hotkeys are not working on Greek layout.
> LibreOffice: Hotkeys are not working on Greek layout.
> Mozilla Firefox: Hotkeys are not working on Greek layout.
> Chromium Browser - Google Chrome: Hotkeys are working on Greek layout.
> Global shortcuts are probably working, for example ctrl+alt+T
> (gnome-terminal) shortcut works, super key +S works too (i haven't tested
> more shortcuts).
>
> Hope that it's going to help.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout in 13.10
>
> Status in IBus:
> New
> Status in Indicator keyboard:
> Triaged
> Status in Unity:
> Invalid
> Status in “gnome-settings-daemon” package in Ubuntu:
> Triaged
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ibus/+bug/1226962/+subscriptions
>

[Filippos Kolyvas (fkol-k4)]

@ Dmitry:
This is somewhat different, i don't mean that i can't change layout with some custom shortcut. I'm using the default shortcuts (super+space, shift+super+space) and these do not work anymore.

But this is not the reason why i mentioned it, of course we can deal with that later. The reason was that prior to the upgrade through the PPA, when i was "confirming" the layout change with the mouse (i mean change the layout to Greek through super+space and then change it to Greek once more with the mouse), made the shortcuts work on Gedit Text Editor (but not on global shortcuts).

You can see the relative attached picture on comment #5 of duplicate bug #1228422 of similar test results:
https://bugs.launchpad.net/unity/+bug/1228422/+attachment/3834215/+files/greek-layout-saucy.png
This was true until now.

Thanks for your time

[Jacob Popov (j-a-popov)]

Dima, your patch works but partially.

It works fine if I switch layout with XKB hotkey.
However, it doesn't work if I switch using the indicator (which utilises iBus, I presume?).

Steps to reproduce:
1) Launch LO:Writer.
2) Enter some text
3) Try to cut it with Ctrl+X and paste with Ctrl+V (or undo with Ctrl+Z).
4) Change the layout using Alt+Shift and repeat no.3. Works fine.
5) Change the layout using the indicator and mouse and repeat no.3 again. No luck. :-(

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:indicator-keyboard at revision 133, scheduled for release in indicator-keyboard, milestone Unknown

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package indicator-keyboard - 0.0.0+13.10.20131010.1-0ubuntu1

---------------
indicator-keyboard (0.0.0+13.10.20131010.1-0ubuntu1) saucy; urgency=low

  [ William Hua ]
  * Don't set LightDM's layout if we're in a session. (LP: 1226962).
    (LP: #1226962)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 134
 -- Ubuntu daily release <email address hidden> Thu, 10 Oct 2013 12:36:09 +0000

[Evgecyn (evgecyn-deactivatedaccount)]

Ubuntu 13.10. I use colemak and russian layouts. After fix this bug, hotkeys in russian layout work like by using qwerty. I press different hardware keys for the same hotkey combination in different layouts. In ubuntu 12.04 it works fine, the same hardware keys for russian and colemak layouts.

[Igor Zubarev (igor.zubarev)]

Still can't assign CAPS LOCK to switch a keyboard layout.

[Misha Bazanov (bmw-)]

@Igor This bug is not relative, try #1218322

[Roman Vorobets (roman-vorobets)]

I use Dvorak and Russian layouts. Now hotkeys in Russian layout work like the layout was QWERTY, not Dvorak, which is very inconvenient, as I have to use different physical keys when I switch layouts. It worked flawlessly for years, and now it's broken.

[Gilad Ravid (gilad-m)]

I have the same bug (since my last night upgrade to 13.10) the package as describe at #31 installed on my system . I still have that bug

[Andreas Tsourouflis (andreas-tsourouflis)]

I confirm that the bug still remains

[Andreas Tsourouflis (andreas-tsourouflis)]

I have found a workaround here: https://bbs.archlinux.org/viewtopic.php?id=167687

This bug affects only Libreoffice. In other applications (e.g. Gedit, Nautilus, Thunderbird etc.), the shortcuts work even after switching layouts. If you remove libreoffice-gtk and libreoffice-gnome, the problem is solved, although libreoffice becomes very ugly.

It should be noted that the bug affects both Ubuntu 13.10 and UbuntuGnome 13.10. I have tried this workaround in both an Ubuntu and an UbuntuGnome installation. Libreoffice In Ubuntu became unusable, although the bug disappeared, whereas in UbuntuGnome Libreoffice could still be used.

[Filippos Kolyvas (fkol-k4)]

I confirm that the bug is fixed for GTK core applications (gedit, nautilus) and Mozilla Firefox.
Well done @ all who worked in this!

I can also confirm that the bug still affects typing when using LibreOffice and when using KDE applications (such as kate text editor) on Ubuntu with standard Unity desktop environment.

I haven' tested this on UbuntuGnome.

[Norbert (nrbrtx)]

I have installed latest packages from ppa:attente/1218322 (Ctrl+Shift or Alt+Shift or Caps Lock - all work as layout switchers between English and Russian), but shortcuts (such as Ctrl+Alt+T) on non-latin layout do not work (UbuntuGnome, Ubuntu).

[goroskob (goroskob)]

Still got this bug in libreoffice and openoffice.

[Кудрин Сергей (smortus)]

Installed update which fixed <super>+space layout switching bug. Now, for example, can't save all documents in Eclipce with <ctrl>+<shift>+s, or open new terminal tab by <ctrl>+<shift>+t, this hotkeys just switching layout. I'm set switching to <ctrl>+<shift>

Also, can't select whole word with <ctrl>+<shift>+arrow

[Suor (suor-web)]

Also, if <alt>+<shift> is set to switch layout then <alt>+<shift>+<up> and <alt>+<shift>+<down> shortcuts don't work in sublime text 3. After removing keyboard-indicator everything returned back to normal.

[Sys (sysradium)]

Confirm this bug. Someone suggested to switch into non latin layout and set a hotkey using non latin letters. I did that and ended up with a ctrl+alt+t working only with a non-latin layout ...

[ssy (somsaks)]

Confirm this bug too, I am using EN and TH (Thai) layout.

- This bug only affected libreoffice, removing libreoffice-{gnome,gtk} fix it as suggested by comment above.
- Strangely, the <Super>+1 (switch to first application pinned to Dash) always not work (emitting "ๅ" instead).

[ssy (somsaks)]

Forgot to mentioned the version of related packages in my machine

gnome-control-center 3.6.3-0ubuntu45ppa1
gnome-settings-daemon 3.8.5-0ubuntu11.1

[Klass_Ivan (klass-ivanklass)]

As for me, it also affect IntelliJ software.

[Artur Eshenbrener (strate)]

Affected in IntelliJ software too, both on Java6 & Java7.

[Artur Eshenbrener (strate)]

Java8 too

[Norbert (nrbrtx)]

What is interesting - non-latin shortcuts (for example Ctrl+Alt+T) work in GNOME Session FlashBack (with effects), but do not work in Unity and GNOME Session FlashBack (without effects).

[Andreas Tsourouflis (andreas-tsourouflis)]

It seems that this bug is almost entirely LibreOffice-specific. Apparently, the problem lies in the interaction between Libreoffice and the new way that Gnome handles keyboard events with gnome-settings-daemon. A corresponding bug has been filed for LibreOffice (https://bugs.freedesktop.org/show_bug.cgi?id=41169)

I don't use IntelliJ software, which has also been reported to be affected by this bug, but I assume there is the same problem.

[Andreas Tsourouflis (andreas-tsourouflis)]

A workaround that really works:
- Install ibus-m17n package
- Go to System Settings/Keyboard/Layout Settings and add the m17n-layout for your language. In my case (Greek), it was "Ελληνικά (kbd (m17))".
Now, shortcuts should work.

Finally, I 'm afraid that this bug, which has been around for a long time, is underestimated. For non-latin language users who want to use the computer for production purposes, this is not just an annoyance, it's a show-stopper. If I was a Windows user trying Ubuntu for the first time, Ubuntu (and possibly Linux) would never get a second chance.

[Suor (suor-web)]

This is not LibreOffice-specific at all. I can't see how it's even related. Global shortcuts do not work like Ctr+Alt+T. And uninstalling LibreOffice do not help.

[Suor (suor-web)]

Also confirm Andreas' workaround works for me with "Russian (kbd (m17))" layout. Language icon is extremely ugly though.

[ssy (somsaks)]

Andreas workaround works for me with "Thai (kesmanee (m17n))". "Super-1" key now works in every apps. Libreoffice Writer hotkey works too.

The only problem now is that the keyboard indicator logo for my layout is quite ugly, compare to non-m17n version, which is tolerable for me.

[Andreas Tsourouflis (andreas-tsourouflis)]

@suor, @ssy.
There is a workaround for the ugly icons too.
m17n uses the icons located in usr/share/m17n/icons/
In my case (Greek), it was "el-kbd.png".
You can substitute the m17n-icon with an icon of your liking. I have tried to use the default Unity icon located in /usr/share/icons/ubuntu-mono-dark/status/22/ and it works even though the Unity icon is in svg format
Namely, I have renamed "indicator-keyboard-Gr.svg" to "el-kbd.png" and placed it in usr/share/m17n/icons/

I am not sure whether it works all the time. Please confirm

[Norbert (nrbrtx)]

I think that bug 1218322 (and bug 1226962; and other tagged with keyboard-layout-switching-related and keyboard-layout-switching-hotkeys) can be marked as fixed only if all hotkeys for layout switching that may be set with current next-source<->previous-source logic:
1. can be set ;
2. can be used in Unity session and in GNOME FlashBack session (with and without effects) and in Ubuntu GNOME ;
3. do not brake other shortcuts (for example, Ctrl+Shift must allow to use Ctrl+Shift+C/V in gnome-terminal, use Ctrl+Shift+arrows for text selecting, etc.).

So we need testers that can verify that all possible hotkeys are working normally. Test results may be written in Google Docs table (https://docs.google.com/spreadsheet/ccc?key=0Ao5e713Ig9g_dEJrX2NRYlpLWWVzSWxsVXU4ck9HYVE&usp=sharing).

[Norbert (nrbrtx)]

Updated to latest versions (gnome-control-center 1:3.6.3-0ubuntu45.1, gnome-settings-daemon 3.8.5-0ubuntu11.1) and bug is still here.

[hero1900 (hero1900)]

after the last update i can assign Alt+Shift to change the text entry :)

[Norbert (nrbrtx)]

@hero1900
Here we speak about broken hotkeys on non-latin layout. Did gnome-terminal opened after Ctrl+Alt+T were pressed on non-latin layout?
For Alt+Shift hotkey we have separate bug 1245926.

[hero1900 (hero1900)]

owh my wrong still the same. all these bugs related to each other after the
new text entry in 13.10 and i got confused

On Tue, Nov 5, 2013 at 2:03 AM, Norbert <email address hidden> wrote:

> @hero1900
> Here we speak about broken hotkeys on non-latin layout. Did gnome-terminal
> opened after Ctrl+Alt+T were pressed on non-latin layout?
> For Alt+Shift hotkey we have separate bug 1245926.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout in 13.10
>
> Status in IBus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Unity:
> Invalid
> Status in "gnome-settings-daemon" package in Ubuntu:
> Triaged
> Status in "indicator-keyboard" package in Ubuntu:
> Fix Released
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
> ----------
> For other layout switching problems introduced in Ubuntu 13.10 you can
> see bug 1218322.
> ----------
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ibus/+bug/1226962/+subscriptions
>

[Andrei Karpenko (andy-karpenko)]

This bug also affects Netbeans (which is Java-based).

[Misha Bazanov (bmw-)]

I use workaround by Andreas (#52), it works, but now language switch ignored by steam client. Only english abalible in steam client.

[Ddv64 (ddv64)]

All hotkeys are not working in all keyboards, except English.

Verified and reproduced on: 4.1.2.3 on Ubuntu 13.10

Steps to reproduce:
1. Launch Writer.
2. Change language to Russian and write a text, then select a part of it.
3. Press Ctrl+X to cut a text.

Error: Text will be on screen

Expected: To cut selected text.

Workarounds to use toolbar buttons or select English keyboard layout, use shortcut, select Russian layout.

It is very important bug because make work very slow.

[Mikola (panamik)]

Norbert (nrbrtx), thanks for the Google Spreadsheet - this is great to have status overview for all possible combinations in one place.

You wrote:
-----------
...can be marked as fixed only if...
3. do not brake other shortcuts (for example, Ctrl+Shift must allow to use Ctrl+Shift+C/V in gnome-terminal, use Ctrl+Shift+arrows for text selecting, etc.).
-----------

Should we add a couple of cases to the spreadsheet covering this criteria?
I.e.
 - Ctrl+Shift+<something> - you listed some good examples for this one
 - Alt+Shift+<something> - so far I see the problem in IntelliJ IDE (I believe people mentioned it above - it has many actions mapped to Alt+Shift+<something>), and also in JIRA (web based bug tracking system, which has hotkeys like Alt+Shift+S to save document). I understand all these are not commonly used applications (they are dev tools), so I'm trying to find out more widely used application using Alt+Shift+<something> keyboard shortcuts.

[Norbert (nrbrtx)]

@Mikola (panamik)
Thank you for great idea.
I created a sheet named "Non-latin shortcuts" in my table (https://docs.google.com/spreadsheet/ccc?key=0Ao5e713Ig9g_dEJrX2NRYlpLWWVzSWxsVXU4ck9HYVE&usp=sharing). I added simple shortcuts to it (Ctrl+Alt+T, Ctrl+Shift+C/V in gnome-terminal).
You and/or other users may add more shortcuts to it. Table is writable by anyone with link.

I hope, that my table will help William Hua and other Ubuntu developers to fix and verify hotkey related bugs.

[Rui Matos (tiagomatos)]

*** Bug 55585 has been marked as a duplicate of this bug. ***

[Rui Matos (tiagomatos)]

See https://bugs.freedesktop.org/show_bug.cgi?id=55585#c0 for why this happens and how it could be fixed.

[Klass_Ivan (klass-ivanklass)]

As for me, solution via m17 don't work at all - it changes only indicator, but not a keyboard layout - it still types in english even for "Russian (kbd (m17))". It also doesn't show Keyboard Layout Chart properly - when this button is pressed, it shows window with English (US) chart.

[Andreas Tsourouflis (andreas-tsourouflis)]

@Klass-Ivan
The workaround with m17n concerns the use of hotkeys with different layouts and not switching between those layouts. For switching layouts there is a separate bug (1218322)

[Artem M. Pelenitsyn (ulysses4ever)]

The workaround by Andreas (#52) seems to be broken (for me, at least) by the last update of gnome-control-center - 1:3.6.3-0ubuntu45.1 — which partially fixes 1218322 bug concerning hotkeys for layout switching ( https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1218322 ). It worked before the update, but now switching to "Russian (kbd (m17))" doesn't take effect at all (the layout stays latin).

[peerus (tsifra)]

Maybe it's related problem but when there is no window focused keyboard inicator doesn't show any changes after needed keys pressed. Hotkeys like Ctrl-Alt-L also don't work. Couldn't reproduce it right now. But i've seen this this morning. No software upgrades after. I'm on gnome shell

[Vstuart-foote (vstuart-foote)]

*** Bug 59045 has been marked as a duplicate of this bug. ***

[Vstuart-foote (vstuart-foote)]

*** Bug 71358 has been marked as a duplicate of this bug. ***

[مصعب الزعبي (moceap)]

== TESTS WE DO ==

This bug found in:
- Fedora 19 Gnome Shell
- Fedora 19 Mate
- Ubuntu 12.04 Unity
- Ubuntu 12.04 Cinnamon
- Ubuntu 13.10

This bug not found in:
- Fedora 19 KDE
- Mint 15 Cinnamon
- Mint 15 XFCE
- Debian 7.1
- Debian - nonstable XFCE
- Ubuntu 10.04 Gnome 2.30
- Arch KDE

Current behavior:
Accelators don't work
Expected behavior:
Accelators works

Operating System: Linux (Other)
Version: 4.1.2.3 release

[Grief (iamgrief)]

I just want to share a workaround which I've found on several russian forums.

1. Let you have cleanly installed 13.10. You might want to add some additional keyboard layouts if you didn't do that during the installation. For me, there are RU and EN layouts.
2. English layout must be the first one in the list. You won't use system layout switcher, so it always be shown in English. You can disable the icon and the layout changing keyboard shortcuts if you know how.
3. Install gxneur. You, probably, can use the default repo, but I didn't try that and prefered to use Andrew's own ppa:

sudo add-apt-repository ppa:andrew-crew-kuznetsov/xneur-unstable
sudo apt-get update
sudo apt-get install xneur

4. For enabling the tray icon you can use the following:
gconftool-2 -s -t string /apps/gxneur/rendering_engine AppIndicator

Now go to gxneur settings and feel free to setup everything as you want. I would recommend you to turn on only manual corrections as automatic ones could be really annoying and even frustrating.

I set ctrl+shift to change the layout and don't experience difficulties with ctrl+shift+[key] shortcuts independently of the current layout now.

[Norbert (nrbrtx)]

It seems that this problem exists in other distros, which do not have indicator-keyboard and use GNOME 3.8 and 3.10 (I mean AltLinux p7, Sabayon, Mageia 4). So we need to report to upstream.

[Norbert (nrbrtx)]

I reported to upstream.

[Norbert (nrbrtx)]

712669 is a duplicate of 678001

[Majed Aly (majed-aly)]

I tried the workaround offered by Grief, using xneur on bilingual Ubuntu 13.10 using Arabic as an alternative layout. Xneur is so buggy with Arabic, where it does not practically work. Had to uninstall it.
Still the problem persists with system shortcuts, and libreoffice.
Using Allow different sources for each window, and setting New windows use the default source in text entry settings, makes it less painful, and isolating the problem within libreoffice only, as the system would default to English for system shortcuts.

[Caolanm (caolanm)]

The original report is from the Mac, but the recent storm is for gtk. There are different backends involved. So there are really two different bugs in here. A Mac one and a Gtk one.

[Libreoffice-commits (libreoffice-commits)]

Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8cef6c7ec67aec88b339ca647e784afbabf190f8

Related: fdo#41169 fix GTK non-Latin keyboard layout with Latin shortcuts

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=390b9d88c47347ebc714808979fcf8bd4e66f5c1&h=libreoffice-4-2

Related: fdo#41169 fix GTK non-Latin keyboard layout with Latin shortcuts

It will be available in LibreOffice 4.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=82b5172954261e030a42bd6b3f4acc99807d0ee5

Resolves: fdo#41169 fix MacOSX non-Latin keyboard layout with Latin shortcuts

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

[Caolanm (caolanm)]

And the last patch should allow stuff like ctrl+b to work on the mac even if the current keymap is Russian, which is the other older half of this problem apparently.

[Julius (juliusn)]

the libreoffice shortcuts make me really mad (( everytime when i forget to change my keyboard layout to EN. I fucked up my copy/paste. Guys, I'm begging you, please, fix this annoying bug.

[Libreoffice-commits (libreoffice-commits)]

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d77483f0ab1a7f97ec41adfac66d98696adeef70&h=libreoffice-4-1

Related: fdo#41169 fix GTK non-Latin keyboard layout with Latin shortcuts

It will be available in LibreOffice 4.1.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5677b7a9e4d33d07e1f5ad9e5d591beb242c2dd6&h=libreoffice-4-1

Resolves: fdo#41169 fix MacOSX non-Latin keyboard layout with Latin shortcuts

It will be available in LibreOffice 4.1.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=341dfe3a2e0f6f9e5bc1e7985cc4ccd00cf733ee&h=libreoffice-4-2

Resolves: fdo#41169 fix MacOSX non-Latin keyboard layout with Latin shortcuts

It will be available in LibreOffice 4.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

[Shahab Shahsavari Alavidjeh (zzgraph)]

While I had trouble with this bug for a long time, I recently discovered that using m17n keyboard layout instead of xkb layout for Persian (fa_IR) completely resolves the problem in libreoffice 4.1.3 gnome 3.8.

[Shahab Shahsavari Alavidjeh (zzgraph)]

(In reply to comment #37)
> While I had trouble with this bug for a long time, I recently discovered
> that using m17n keyboard layout instead of xkb layout for Persian (fa_IR)
> completely resolves the problem in libreoffice 4.1.3 gnome 3.8.

And I think the keyboard is actually Latin keyboard, my comment was completely irrelevant.

[mamay (melnykog)]

ubntu 13.10 latest upgrade: intellij, android studio libre office - hot keys in non-latin keyboard doesn't work.

[mamay (melnykog)]

actually in intellij another possibly related issue: when switching between windows with ctrl+tab whole keyboard can be frozen (disabled) so you cannot type only mouse event, then it needs to be restarted. Started only after 13.10 upgrade.

[Bogdan Yurov (nick4fake)]

Latest updates (as of 01.12) with latest java and IntellijIDEA - there is the same bug.
Ubuntu 13.10 is still unusable.

[Alexey Kulik (doctor-rover)]

I can confirm that with modifier-only-input-switch PPA activated, hotkeys in non-latin layout work fine in most applications except for some of them.
I encounter non-latin-layout-hotkeys malfunction in LibreOffice and VLC.

[John Rotomano (rotomano)]

Can confirm the bug with Apache Openoffice 4.0.1 AOO401m5(Build:9714
in Ubuntu 13.10

[Anton Statutov (astatutov)]

This bug is still actual for most applications after all updates have been applied. All workarounds specified in this bug are not usable anymore.

[ssy (somsaks)]

I'm still using m17n workaround and it still works for me (including LibreOffice).

[Andreas Tsourouflis (andreas-tsourouflis)]

@astatutov
The m17n workaround (#52) has never stopped working. Sometimes, after some updates the switch became a little slow, however it keeps working flawlessly. Even the icon workaround (#56) has no problems

[Anton Statutov (astatutov)]

@andreas-tsourouflis
I have tried m17n, but it didn't switch layouts at all, though the indicator did change its icon. The same problem was described in comment #68.

[Anton Statutov (astatutov)]

UPD: ok, m17n partly works. It doesn't work only in Kate on my computer (but works on nearby computer with exactly same configuration). Also there are some side effects in some applications like Thunderbird: if you type symbols in it then Ctrl+Z will revert all symbols one by one (this is not correct behavior).

Offtopic: I really don't understand Ubuntu's team politics. What the reason to rewrite and completely break such a essential functionality as layout switching in "stable" release (and force users to update to this release)?

[Saveliy Tretiakov (st-t)]

Upgrade to 13.10 has made my system almost unusable because of this bug. Hotkeys in non-latin layouts stopped working (especially in Intellij Idea). Now I have to reinstall everything to revert to 13.04. This is so discouraging.

[Norbert (nrbrtx)]

@Anton (@85), @Savely (#86)
I can't understand why you do not use Ubuntu 12.04.3 LTS. What is a reason to use non-LTS Ubuntu release for programming or other non-hobby tasks?

IMHO below.
In present time many problems come from GNOME fast destruction and simpility/stupidity behavior.
GNOME reduces its functionality very fast, and this changes are not tested for all regressions and bugs, this changes are not discussed with gnome-users.
So many problems are common for all distros - i.e. Ubuntu 13.10, OpenSuSe 12.3, Fedora 20, Mageia 4 and others will use the same buggy and untested GNOME 3.x. As the most conservative solution we can use CentOS 6.5 (with GNOME 2.28 !! ) or Gentoo (with GNOME 2.32), but this solution is not universal for all users.

So If you choose Ubuntu, I recommend to use Ubuntu LTS on all PCs and laptops on which you do real work.
For example, in system requirements for Android SDK Google mark Lucid Lynx (10.04, previous LTS) as tested Linux development platform (see http://developer.android.com/develop/index.html).

[Anton Statutov (astatutov)]

@Norbert
Ubuntu 12.04 was not more stable then 12.10 or 13.04. It's even not claimed to be more stable by Canonical, as it's just long term support. Many applications of older versions aren't usable for real tasks. I can name some examples. GIMP 2.6 (from 12.04) has no layer groups support, so it was completely useless to open PSD-files. OwnCloud 5.0.4 (also from 12.04) has some deal-breaking bugs and known vulnerabilities, making it completely unusable. And the same for ownCloud client. LibreOffice 1.3 is one more example, it's not usable on some complex files. We use OS not for itself but for applications, so LTS is not a solution at all. In other words we need stable base system and fresh applications, but there is no such a choice for Ubuntu.

[Suor (suor-web)]

Stable old system even with new applications is not an option for many
developers. Cause of old kernel, standard libraries and such.

For example, my touchpad won't work on older kernels and many other
hardware in newer laptops. I once struggled for substantial amount of time
to compile node.js on CentOS cause of old stdlib. It's also much harder to
install new versions of Python, Perl, Ruby, gcc on older distributions.

And anyway, proposing to not upgrade to stable release to not get severe
bugs sounds very strange.
05 дек. 2013 г. 23:11 пользователь "Anton Statutov" <
<email address hidden>> написал:

> @Norbert
> Ubuntu 12.04 was not more stable then 12.10 or 13.04. It's even not
> claimed to be more stable by Canonical, as it's just long term support.
> Many applications of older versions aren't usable for real tasks. I can
> name some examples. GIMP 2.6 (from 12.04) has no layer groups support, so
> it was completely useless to open PSD-files. OwnCloud 5.0.4 (also from
> 12.04) has some deal-breaking bugs and known vulnerabilities, making it
> completely unusable. And the same for ownCloud client. LibreOffice 1.3 is
> one more example, it's not usable on some complex files. We use OS not for
> itself but for applications, so LTS is not a solution at all. In other
> words we need stable base system and fresh applications, but there is no
> such a choice for Ubuntu.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout in 13.10
>
> Status in IBus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Mutter:
> New
> Status in The OpenOffice.org Suite:
> New
> Status in Unity:
> Invalid
> Status in “gnome-settings-daemon” package in Ubuntu:
> Triaged
> Status in “indicator-keyboard” package in Ubuntu:
> Fix Released
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
> ----------
> For other layout switching problems introduced in Ubuntu 13.10 you can
> see bug 1218322.
> ----------
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ibus/+bug/1226962/+subscriptions
>

[Péter Prőhle (prohlep)]

Dear Norbert!

> IMHO below. In present time many problems come from GNOME fast
> destruction and simpility/stupidity behavior. GNOME reduces its
> functionality very fast, and this changes are not tested for all
> regressions and bugs, this changes are not discussed with gnome-users.
> So many problems are common for all distros - i.e. Ubuntu 13.10,
> OpenSuSe 12.3, Fedora 20, Mageia 4 and others will use the same buggy
> and untested GNOME 3.x. As the most conservative solution we can use
> CentOS 6.5 (with GNOME 2.28 !! ) or Gentoo (with GNOME 2.32), but this
> solution is not universal for all users.
>
> So If you choose Ubuntu, I recommend to use Ubuntu LTS ...

Thanks for your detailed explanation, now I understand better why it is
lucky, that my daugther (physicist and chemist) uses LTS. So I will
leave her LTS alone until the next LTS.

Best wishes,
  Peter.

[Dilshod Mukhtarov (dilshodm)]

Ctrl-Alt-T doesn't open Terminal in russian layout.
However, with m17n workaround works OK.

[Péter Prőhle (prohlep)]

> Ctrl-Alt-T doesn't open Terminal in russian layout.
> However, with m17n workaround works OK.

Is there a latin letter T in the russian layout?

I mean a real latin letter T, and not only a correspondig cyrillic letter.

This is the REAL question.

While it is not comfortable, but it is according to the standards, that if
there is no FOO in a layout, then there is neither Ctrl-Alt-FOO in the
same layout.

If "terminal" in russian begins with the CYRILLIC letter say X, then you
should open your terminal with Ctrl-Alt-X.

I guess that m17n workaround is a tool to break the standards.

I understand you, I also suffer from the fact, that I am neither a native
english speaker. But there is no equal opportunity in this partikcular
World. We have no equal chances. We have to afford more efforts to
achieve the same result.

  Peter.

[Thanos Kyritsis (djart)]

> Is there a latin letter T in the russian layout?

There is a letter T in the Greek layout. Also, "terminal" in Greek translates to "τερματικό", both words start with a letter T. So, there is no excuse for the Ctrl-Alt-T Unity shortcut not working in Greek layout.

Unfortunatelly, iBus breaks whatever stability, maturity and standards-compliance XKB built for over one decade.

[Péter Prőhle (prohlep)]

> There is a letter T in the Greek layout. Also, "terminal" in Greek
> translates to "τερματικό", both words start with a letter T. So, there
> is no excuse for the Ctrl-Alt-T Unity shortcut not working in Greek
> layout.

Greek T is NOT identical to Latin T, they are DISTINCT letters, which only
correspond to each other.

This is not only a valid excuse, but otherwise we were not able to write a
pure greek text containing properly shaped greek T letters.

In other words, the unicode code point of greek T and latin T are luckily
different.

Even "τερματικό" is not identical to "termatiko", there is only a natural
correspondance there.

Hence the correct solution is if Ctrl-Alt-τ works instead of Ctrl-Alt-t.

While it is just a minor amount of difference in terms of the visual shape
of the letters, but an essential difference in terms of unicode code
points of them.

I have no greek keyboard experince, but I am reluctant to think that your
greek layout produces latin-t instead of greek-τ. Hence Ctrl-Alt-τ should
work instead of Ctrl-Alt-t.

I think that all of you have implicitely the following suggestion:

  the keyboardlayout should be Alt, Ctrl and Ctrl-Alt dependent

and even if the plain state produces russian or greek letters, the Alt,
Ctrl and Ctrl-Alt layers should be able to remain in US-English layout.

However this would need the redesign of the keyboarlyout config tools, in
order to make the users able to specify the 4 different layers: the plain,
the Alt, the Ctrl and the Ctrl-Alt layers INDEPENDENTLY from each other.

  Peter.

[Thanos Kyritsis (djart)]

Ok, they are not identical, you are right. But it doesn't matter, actually. What matters is that the *physical* keyboard shortcuts like Ctrl-Alt-T or Ctrl-C, Ctrl-V should just work no matter what the current layout is. This is also what XKB achieved after many years of maturity, simple as that!

[Péter Prőhle (prohlep)]

> What matters is that the *physical* keyboard shortcuts like Ctrl-Alt-T
> or Ctrl-C, Ctrl-V should just work no matter what the current layout is.

That is, what you say, that the four layers, i.e. the plain, the Alt, the
Ctrl and the Ctrl-Alt layers shuld be INDEPENDENT-ly configurable, and so
we could keep the Ctrl-Alt layer in US-English layout. This is the
implicite suggestion what I was mentioning at the end of my previous
comment.

If a layer is kept in the US-English layout, then we call it as that
particular layer is in *physical* keyboard layout.

  Peter.

[Misha Bazanov (bmw-)]

Péter you are right, if we think about layouts/unicode/etc. Not about hotkeys.
Hotkeys should be independent of keyboard layouts. In another case, it spoils the whole idea of hotkeys and makes them impossible to use.
[ctrl, alt, meta (in any combination)] and some letter in non-latin layout must be converted to [ctrl, alt, meta (in any combination)] and latin letter(or symbol) at the same button on keyboard. If it contradicts the standard, it is a stupid standard.
example:
Russian ё converted to `
н - y
ж - ;
Greek:
γ - g
θ - u
ρ - r

So we need only one system latin layout for hotkeys - drawed on the keyboard. It may be engish, german or other.
All hotkeys in non-latin layouts should be converted to this layout.

[Lior Kaplan (kaplan)]

I could not verify the fix on a build from master, Debian testing 64bit, GNOME 3.8 with Hebrew keyboard layout.

While using the Hebrew layout I can't use CTRL+C/V or CTRL+O in LibO. Switching to another application (e.g. a web browser) I could paste with CTRL+V although I'm in the Hebrew layout.

[John Rotomano (rotomano)]

This bug has been fixed in the LIBREOFFICE 4.2 beta.

Still appears in OPENOFFICE 4.0.1 and all other affected applications in Ubuntu 13.10.

[Simos Xenitellis  (simosx)]

A bit of essential fact-checking:

X.Org/XKB consider different the shortcuts like Ctrl+T (latin t) and Ctrl+Τ (greek τ) and so on. Because they are different characters. Obviously.

It is because of gtk+ (with gtk+ input method) that shortcuts like Ctrl+Τ (greek τ) work just like Ctrl+T (latin t). This has been really amazing and usable, and we all like it. It's a gtk+ feature (if you use the gtk+ input method), and when we move to different toolkits/input methods, we need to make an effort to replicate the functionality.

Apart from an amazing feature, it is also a hack. It makes a mess to those that use "unconventional" layouts like dvorak. Ok, those are a minority compared to us...

In this report, the source of the issue is either not using the gtk+ input method in gtk+ apps, or non-gtk+ apps (which obviously do not use the gtk+ input method). Also, there might be cases (I am speculating) that keyboard filtering might mess up as well.

If you want to figure out whether the gtk+ input method is actually working, you can type Ctrl+Shift+u (latin 'u'), then type aa and then press spacebar. If you get ª, then the gtk+ input method is working for you.

[Norbert (nrbrtx)]

It seems that Ubuntu 14.04 is affected too - unable to use shortcuts on non-latin layout in LibreOffice.
But Ctrl+Alt+T, Ctrl+Shift+C/V works in gnome-terminal normally.
Tested in Unity session.

[Björn Michaelsen (bjoern-michaelsen)]

As per:
https://bugs.freedesktop.org/show_bug.cgi?id=41169#c35
this has been worked on for LibreOffice 4.1.4, which has been released to the ppas:
https://launchpad.net/~libreoffice/+archive/ppa
https://launchpad.net/~libreoffice/+archive/libreoffice-4-1

Please test, if this fixes the issue it might be SRUed.

[Norbert (nrbrtx)]

Thank you, Björn Michaelsen!

I installed 4.1.4~rc2-0ubuntu1~trusty1~ppa1 from libreoffice ppa, shortcuts work normally. Tested on Cyrillic layout.
So we need SRU for Trusty.

[Nrbrtx (nrbrtx-redhat-bugs)]

This bug exists in Ubuntu too https://bugs.launchpad.net/unity/+bug/1226962 (200 users affected).

[Nrbrtx (nrbrtx-redhat-bugs)]

This bug exists in Ubuntu too https://bugs.launchpad.net/unity/+bug/1226962 (200 users affected).

[Nrbrtx (nrbrtx-redhat-bugs)]

GNOMErs think that corresponding bug is https://bugzilla.gnome.org/show_bug.cgi?id=678001 .

[Majed Aly (majed-aly)]

I can confirm that the solution suggested by Norbert works. Just add the following ppa to your system
sudo add-apt-repository ppa:libreoffice/libreoffice-4-1
sudo apt -f update
sudo apt-f upgrade
#Then it will remove the olf libreoffice leaving broken packages
sudo apt-f install
#will fix the repository
#Then use
sudo apt-get install libreoffice-writer
sudo apt-get install libreoffice-calc
sudo apt-get install libreoffice-base
sudo apt-get install libreoffice-draw
#to install the new packages. Works for bilingual Arabic/English keyboard, Ubuntu 13.10
# Thanks to all contributors, now LibreOffice is usable again !

[Michael Zheludkov (zheludkovm)]

wrote simple walkround for java gui apps (netbeans, soapui, jetbrains idea etc)
https://github.com/zheludkovm/LinuxJavaFixes

by default it use only russian to latin button bindings
but you can create any binding by yoyrself

[Klass_Ivan (klass-ivanklass)]

Many thanks to Michael Zheludkov!
Worked like a charm with pycharm :)))
Comparing to other workarounds yours is the most safe (its seen that it won't affect anything) and easy to enable/disable.
Wow!

[Saveliy Tretiakov (st-t)]

Thanks a lot to Michael Zheludkov for the fix, but I want Intellij Idea hotkeys to work out of the box without any workarounds. Just as they worked before. When will this be possible in ubuntu?

[Michael Zheludkov (zheludkovm)]

My friend asked me to patch also Eclipse SWT.
Just added to https://github.com/zheludkovm/LinuxJavaFixes patch for Eclipse.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:unity at revision 3650, scheduled for release in unity, milestone 7.2.0

[Leeron Rabinov (lax2tlv)]

ֹUnsure if this is the same bug or even related; however, the issue persists with the Hebrew keyboard layout (while absent in (a) other Hebrew layouts (lyx, phoenetic) (b) other languages, including RTL (Russian, Arabic tested)).

Ubuntu 13.10 64-bit
Unity 7.1.2
LibreOffice 4.2.0.4

Steps to reproduce:

1. Add Hebrew keyboard layout.
2. Open Writer.
3. Switch to Hebrew layout.
4. Type a string.
5. Attempt to use CTL+A/C/V/X.

[Stéphane Guillou (stephane-guillou)]

Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity - 7.1.2+14.04.20140214.1-0ubuntu1

---------------
unity (7.1.2+14.04.20140214.1-0ubuntu1) trusty; urgency=low

  [ Sebastien Bacher ]
  * use unity-control-center by default.
  * lists keybinding in unity-control-center. (LP: #1271710)

  [ Brandon Schaefer ]
  * Bump to new libnux from this branch:
    https://code.launchpad.net/~brandontschaefer/nux/xim-preedit-
    support.
  * Adds Super+L to lock the screen, while keeping the older shortcut
    around in g-s-d (Ctrl+Alt+L). (LP: #830709)
  * Do not open the dash/hud on a monitor with a top most window that is
    fullscreen. (LP: #1267210)
  * Implement an EMConveter. This way with default settings such that
    DPI = 96.0f, and font_size = system font size. We can get the
    correct EM value for any pixel size. Once we have the correct EM
    value for any pixel size, the DPI value can be adjusted to the
    current logical one. From here, you can now get the correct pixel
    size based from of the EM value for the logical DPI of the screen.
  * Refactor EMConverter API. Now all thats needed is int
    ConvertPixels(int pixel); This will calculate the correct pixel size
    based on the DPI and font size.
  * Testing that the ibus anthy tests could possibly be causing strange
    issues on the nvidia machine. So skipping them to test if tihs is
    the source of the error.
  * Add Pt to Px function to em converter.
  * Move EMConverter over to unity settings.
  * Add multi monitor support for EMConverter in unity settings. Now you
    can grab a specific converter per monitor.
  * Simple RawPixel class. It adds 2 define literals, ex: 10_em,
    10.0_em. From there it turns them into raw pixels. RawPixels have CP
    (CovertPixel) function which takes in an EMConverter that allows you
    to use a converter specific to a monitor to convert the raw pixel to
    the correct value.

  [ Marco Trevisan (Treviño) ]
  * Don't re-present all of our windows on every frame. Only do that if
    damage intersects it. Use the new APIs exposed by compiz and nux to
    intelligently determine which windows need to be presented per-frame
    and only register damage for those windows. This fixes two things:
    1. BaseWindows being redrawn from scratch every time damage was
    registered over them. That was incorrect and should only be done in
    the case of background blurs. 2. BaseWindows being drawn to the
    screen on every frame, regardless of whether or not they needed to
    be. Now they will only be drawn if some damage intersects beneath
    them. Note that unity will expand the damage region to accomadate
    the base window since nux does not support geometry clipping. So if
    there is a partial intersection of the launcher for example, the
    area of the screen which contains the launcher will be re-painted
    (but the launcher itself won't be redrawn, just its texture) (LP:
    #1080947). (LP: #1080947)
  * Convert compiz regions / rects to nux::Geometry's and back easily.
  * UnityScreen: remove the useless and expensive gl{Push,Pop}Attrib
    calls For some reasons this code was copied by the opengl plugin as
    a workaround to fix the s...

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-settings-daemon - 14.04.0+14.04.20140219-0ubuntu1

---------------
unity-settings-daemon (14.04.0+14.04.20140219-0ubuntu1) trusty; urgency=low

  [ David Henningsson ]
  * Handle unknown audio jack devices.

  [ William Hua ]
  * Revert the legacy key grabber. (LP: #1226962)

  [ Sebastien Bacher ]
  * backport upstream change to support hi-dpi screens/scaling. You can
    change the scaling value by writting the
    "org.gnome.desktop.interface scaling-factor" gsettings key
 -- Ubuntu daily release <email address hidden> Wed, 19 Feb 2014 10:44:06 +0000

[Ivan Larionov (xeron-oskom)]

14:04. Unity hotkeys (cmd+a/f/m/c/v) still doesn't work in non-latin layout.

[Paulo Fino (finomeno)]

Hello everyone!

After months of switching layouts and banging my head against this bug, I thought I should check LibreOffice settings (I'm using 4.1.5.3 now). What figures? I did find something. And in just a few clicks.

This is not a bug! It's simply a matter of configuration.

For the regular keyboard shortcuts (like Ctrl+C, Ctrl+V, etc.) to remain operational in LibreOffice applications while using a non-latin keyboard layout (like Greek or Russian), go to Tools -> Options -> Language Settings -> Languages, check the Ignore system input language option, save, and Bob's your uncle.

Hope this helps.

Cheers!

PS
Technically, though, shortcuts still remain language-dependent. This means if you enable this option, you will have to set your document languages manually.

[Infusiastic (infusiastic)]

The problem is with formatting shortcuts like Ctrl-B/Command+B and Ctrl-I/Command+I shortcuts that still don’t work after Setting “Ignore system input language option”. Ctrl-S/Command-S works even without this setting.

[Masoud Abkenar (mabkenar)]

 Please also take a look at a very similar bug report 1280759. It is not fixed yet.

[Andrew Nenakhov (andrew-nenakhov-redsolution)]

I confirm everything Roman Vorobets said, https://bugs.launchpad.net/unity/+bug/1226962/comments/35

Now when using Dvorak and Russian layouts hotkeys are on one physical key when in English-Dvorak layout, and on other key when in Russian (they are placed to position where corresponding latin key was in QWERTY layout). It worked flawlessly for years, and now it's broken in the same way as in Windows, wich never figured out to fix it.

[Norbert (nrbrtx)]

I installed today's daily image (2013-03-16).
I unable to start gnome-terminal in GNOME FlashBack session (Metacity) with Ctrl+Alt+t on non-latin (cyriliic layout Ctrl+Alt+е). But I can start in Unity and GNOME FlashBack (Compiz) sessions.

Please fix this bug before Ubuntu 14.04 final release.

[Norbert (nrbrtx)]

Made a clean install of Ubuntu 14.04 beta2 ( 4cf9e5ef2c1c362317c90312c76cfda0 *ubuntu-14.04-beta2-desktop-i386.iso).
I unable to start gnome-terminal in GNOME FlashBack session (Metacity) with Ctrl+Alt+t on non-latin (cyriliic layout Ctrl+Alt+е). But I can start in Unity and GNOME FlashBack (Compiz) sessions.

Also I can confirm bug 1280759.
Also there is a big problem with shortcuts, which start from Ctrl+Shift (Ctrl+Shift+C/V in gnome-terminal, Ctrl+Shift+PrintScreen, Ctrl+Shift+Arrows for selecting text in gedit or LibreOffice Writer ) if layout switching key is set to Ctrl+Shift in GNOME sessions (Compiz and Metacity). This is bug 1245473.

Please fix these bugs before Ubuntu 14.04 final release.

For all non-latin shortcut problems you can see my Google Docs table (https://docs.google.com/spreadsheet/ccc?key=0Ao5e713Ig9g_dEJrX2NRYlpLWWVzSWxsVXU4ck9HYVE&usp=sharing , Sheet "!!! Non-latin shortcuts (14.04)").

[Nazar Mokrynskyi (nazar-pc)]

Please, fix this ASAP, I'm waiting with 256+ people more than half of year.

[Norbert (nrbrtx)]

@Stephen M. Webb (bregma)
I do not think that this bug is fixed in Unity since the dependent bug 1280759 (Unity shortcuts (Super+A/F/M/C/V) do not work on non-latin layout in Trusty - shortcuts are defined via keyboard layout, not the keys) is not fixed.
So bug 1226962 is not fixed in Unity.

[Ivan Larionov (xeron-oskom)]

I can confirm Super+A/F/M/C/V still doesn't work in unity.

[Davian818 (davian818)]

*** Bug 77163 has been marked as a duplicate of this bug. ***

[Norbert (nrbrtx)]

Ubuntu 14.04 with all updates for today - problems described in my comment 162 and 164 exist.
Please fix them as soon as possible.

[Michael Soluyanov (crantisz)]

Ubuntu gnome 14.04

Problem with hotkeys:
netbeans 7.2.1 java 1.6.0_31
Blender 2.70
Inkscape (from repos)

hotkeys works only on latin layout

[Dmitry "DeltaKilo" Korotkov (deltakilo)]

Ubuntu 14.04.
Also, affects Intellij IDEA and Rubymine(OpenJDK7 from repos)

Please fix it at soon as possible, that's complete showstopper.

[Igor Bobkov (my-incoming-mail)]

Ubuntu 14.04

Combinations ctrl+C, ctrl+V, ctrl+T... don't work in Krusader (Version 2.4.0-beta3 "Single Step") with non-latin layout.

[CrashIt (nadrshin)]

Ububntu 14.04
Java 1.7.0_51
Netbeans 8.0
Hotkeys (Ctrl+C, Ctrl+V, Ctrl+S, etc.) don't work in non-latin layout.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[CRAFT (craft37)]

Ubuntu 14.04 with latest updates.
Kingsoft Office 9.1.0.4280 (OpenOffice also)

Hotkeys (Ctrl+C, Ctrl+V, Ctrl+S, etc.) don't work in non-latin (cyryllic) layout.

Please fix that old and dummy bag.

[Alexey (allkhor)]

Ubuntu 13.10, 14.04. Hotkeys not work in non-latin [cyryllic] layout for many java programs like:
intellij idea , PyCharm, Minecraft(yeap, game broken too).

But non java programms hotkeys not works too:
Blender, Inkscape.

Please fix that bug, we can't work, every time, we must change keyboard layout!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alexey (allkhor)]

1 Ubuntu 13.10, 14.04 clean installed and last updates
2 English, Russian (cyrillic)
3 Shift+Alt
4 Unity session, other not tested
5 Inkscape 0.48.4 r9939 - Ubuntu repositories,
Blender 2.70a-linux-glibc211-x86_64 binary from blender.org
IntelliJ IDEA 13.1.2 Build: 135.690 binary from jetbrains.com
Hotkeys work only in english layout...

[Norbert (nrbrtx)]

ApportVersion: 2.14.1-0ubuntu3
Architecture: i386
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
InstallationDate: Installed on 2014-04-18 (8 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140417)
Package: unity-settings-daemon
PackageArchitecture: i386
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Tags: trusty
Uname: Linux 3.13.0-24-generic i686
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Artur Eshenbrener (strate)]

Is there any chance to be fixed?

[William Hua (attente)]

If you're using GNOME Shell or Classic and affected in Inkscape/IntelliJ/NetBeans, etc., you can try the PPA here temporarily:

sudo add-apt-repository ppa:attente/java-non-latin-shortcuts
sudo apt-get update
sudo apt-get dist-upgrade

[William Hua (attente)]

Unfortunately the PPA above breaks modifier-only keyboard switching...

[Michael Soluyanov (crantisz)]

William, try to use this comand, it works for me:

gsettings set org.gnome.desktop.wm.keybindings switch-input-source "['<Alt>Shift_L']"

[Michael Soluyanov (crantisz)]

PPA attente/java-non-latin-shortcuts fix problem in NetBeans, but not in Inkscape and Blender... Fix problem in GNOME Shell, please

[Barta-c (barta-c)]

is this bug still valid in 4.2.x branch?
if yes, please move it from mab4.1 to mab 4.2 list since 4.1.x is EOL

[William Hua (attente)]

Hi, I added an update to the PPA for GNOME Shell and Classic. If you could, please do an update, and use the modifier-only input switch option under GNOME control center -> Keyboard -> Typing instead of setting it manually via 'gsettings set org.gnome.desktop.wm.keybindings switch-input-source "['<Alt>Shift_L']"'.

Under Unity, the fix is still in progress, but if you're not using Shift_L, Shift_R, or both Shifts for switching, you might try the PPA to see if it helps the problem.

[unree (unree)]

Bug still present in java programs.

[Giorgi Tepnadze (george-tepnadze)]

PPA attente/java-non-latin-shortcuts fixed problem in LibreOffice 4.2 in Ubuntu 14.04 (Unity) for Georgian-KA language. Thank you

[Artur Eshenbrener (strate)]

PPA attente/java-non-latin-shortcuts fixed problem in IntelliJ Idea in Ubuntu 14.04 (Unity) for Russian language. Thank you.

[DEDan (zsdedan)]

PPA attente/java-non-latin-shortcuts fixed problem in NetUP UTM 5 client in Ubuntu 14.04 (Unity) for Russian language, but after a while the keyboard input stops working.

[William Hua (attente)]

Hi DEDan, where can that client be downloaded? Also, what do you mean by keyboard input stops working? That doesn't sound like a problem with the PPA...

[DEDan (zsdedan)]

William, it can be download here (http://www.netup.ru/UTM5/demo.php) after registration. Sorry, but i can't found english version of this page.

I mean, after installing packages from PPA and then restart the computer for some time it works great, but after a while, the characters no longer be input as if the application freezes. However, I can freely push the buttons and select menu items with the mouse cursor.

I do not know whether this problem to the above PPA or not, but the fact that the application performance deteriorates after installing PPA.

[William Hua (attente)]

DEDan, thanks. Are you using GNOME Shell or Unity? Also, it only happens just in UTM5, not other applications?

[DEDan (zsdedan)]

William, in other java-application no problems are found. Using Unity.

[Saveliy Tretiakov (saveliyt)]

I confirm:
Ubuntu 14.04 with latest updates.
Hotkeys do not work in IntelliJ Idea when non-latin keyboard layout is on.

[DEDan (zsdedan)]

William, I have a few thoughts on the impossibility of keyboard input. I remembered that after upgrading to 13.10 this bug was fixed by removing or restart ibus. But in 14.04 removing ibus will remove many other packages. For a similar bug has already been said here https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/481656

[William Hua (attente)]

Hi DEDan, I'm not sure why IBus affected it, or why removing IBus fixed it in the first place. My intuition says that this is purely a problem caused specifically by the takeover of keyboard layout duties by gnome-settings-daemon. I tested this by moving the /usr/bin/ibus-daemon binary and killing ibus-daemon to stop it, but non-latin keyboard shortcuts were still not working for me in Inkscape. You can try to do this yourself to see if it helps your UTM5 issues, but I can't imagine it helping tbh...

[William Hua (attente)]

Hi Saveliy, you can try the PPA above as long as you're not using Unity with the shift key as your input switcher, it seems to be working in most cases.

[ivan (funivan)]

Confirm Ubuntu 14.04 with latest updates.

This helps me:

sudo add-apt-repository ppa:attente/java-non-latin-shortcuts
sudo apt-get update
sudo apt-get dist-upgrade

Please, fix this bug in main branch.

[daphcnualdaphcnualdaphcnual (ewigekrieg)]

Confirm Ubuntu 14.04 (Unity) with latest updates.

The solution by Attente helps.
Hotkeys with Russian layout now working in LibreOffice 4.2 and Freemind 1.0.

Thanks you very much!
This was really a pain in the ass.

[Artur Eshenbrener (strate)]

Ahhahah, I have made an mistake, writing the https://bugs.launchpad.net/unity/+bug/1226962/comments/190
Now, in JetBrains phpStorm hotkeys work only in ... non-latin keyboard layout :)

[Artur Eshenbrener (strate)]

It is really 100% reproduceable.
I have tried to remove ppa with ppa-purge utility, and hotkeys starts work in latin layout, but stops in non-latin (RU) layout.
Then I hev tried to add ppa again, and situation became inverted: latin layout - no hotkeys, ru layout - working hotkeys.

[William Hua (attente)]

Hi Artur, I just tried PhpStorm with the PPA installed and it seems to work for me (tested ru and gr). What keyboard shortcuts are you trying? Also, can you try to "restart unity-settings-daemon" after installing the PPA to see if that helps?

[William Hua (attente)]

Sorry Artur, I misread your comment... But also trying the hotkeys with en (PPA installed) still works for me...

[William Hua (attente)]

Artur, can you paste the output of 'setxkbmap -query' when you have the 'us' layout active?

[yh1000 (yechiam-halevy)]

​To all,​
The PPA + the "restart unity-settings-daemon" did the trick for me.
(Hebrew)
Perfect.

Thanks

Yechiam

On Thu, May 22, 2014 at 11:04 PM, William Hua <email address hidden>wrote:

> Hi Artur, I just tried PhpStorm with the PPA installed and it seems to
> work for me (tested ru and gr). What keyboard shortcuts are you trying?
> Also, can you try to "restart unity-settings-daemon" after installing
> the PPA to see if that helps?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout in 13.10 and 14.04
>
> Status in LibreOffice Productivity Suite:
> Confirmed
> Status in IBus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Inkscape: A Vector Drawing Tool:
> New
> Status in Mutter:
> Fix Released
> Status in The OpenOffice.org Suite:
> New
> Status in Unity:
> Fix Released
> Status in “gnome-settings-daemon” package in Ubuntu:
> Triaged
> Status in “gnome-terminal” package in Ubuntu:
> Triaged
> Status in “indicator-keyboard” package in Ubuntu:
> Triaged
> Status in “openjdk-7” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> Triaged
> Status in “unity-settings-daemon” package in Ubuntu:
> Triaged
> Status in “gnome-settings-daemon” package in Fedora:
> Unknown
> Status in “gnome-shell” package in Fedora:
> Unknown
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
>
> Dear Ubuntu users and developers!
> Please include the following information to your comment about non-latin
> shortcuts problems:
> 1. What Ubuntu version do you have (Ubuntu 13.10, Ubuntu 13.10 GNOME,
> Ubuntu 14.04, Ubuntu 14.04 GNOME and so on), upgraded (describe version) or
> clean installed
> 2. What keyboard layout do you have
> 3. What shortcut for keyboard layout switching do you use
> 4. On which session you have problems - that is one from Unity, GNOME
> Shell, GNOME FlashBack/Fallback (Metacity), GNOME FlashBack/Fallback
> (Compiz)
> 5. With which program and its version and origin (Ubuntu repositories,
> PPA, non-deb binary package from some website) you have problems.
>
> By providing this information you can make bug-fixing much simpler and
> may be faster.
>
> ----------
> For other layout switching prob...

[Artur Eshenbrener (strate)]

attente, output is here

enabled ppa, us keyboard
% setxkbmap -query
rules: evdev
model: pc105
layout: ru,us
variant: ,

enabled ppa, ru keyboard
% setxkbmap -query
rules: evdev
model: pc105
layout: us,ru
variant: ,

disabled ppa, us keyboard:
% setxkbmap -query
rules: evdev
model: pc105
layout: us,ru
variant: ,

disabled ppa, ru keyboard:
% setxkbmap -query
rules: evdev
model: pc105
layout: ru,us
variant: ,

I should say that I have not almost clean ubuntu 14.04 installation. Is it upgraded from 12.04, and I have tried to install several other DEs, such as Xfce, gnome-session, kde. Now they are removed, but may be some packages are still enabled.

Please, tell me if I should try to make a clean install of 14.04 version.

[Darkskyz1 (darkskyz1)]

Bug still exists in LO 4.2.3.3 on ubuntu 14.04 with hebrew layout.

[Tural Gurbanov (tgurbanov)]

+1
Hotkeys don't work PyCharm 3.1.3 in English (US) layout after PPA + the "restart unity-settings-daemon".

Output of setxkbmap -query:

rules: evdev
model: pc105
layout: ru,us
variant: ,
options: grp_led:scroll

However hotkeys now work in other apps (for ex: chromium) both in EN and RU layouts.

[Yotam Benshalom (benshalom)]

Can these patches to gnome-settings-daemon be submitted to the gnome3 team, so they can merge them in one of their ppa's? This way we will be able to use newer Gnome desktops.

[Artur Eshenbrener (strate)]

Yotam, is this bug also affects pure gnome?

[Yotam Benshalom (benshalom)]

I'm not sure what is pure gnome. It happens to me on 14.04, with http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu and http://ppa.launchpad.net/gnome3-team/gnome3-staging/ubuntu enabled, but WITHOUT Ricotz testing PPA. The unity-settings-daemon is not installed on my system.

[William Hua (attente)]

I don't think we should apply the patches to the gnome3-team's PPAs because they also cause regressions for certain programs like Eclipse, or like Artur's case above.

[Yotam Benshalom (benshalom)]

I think that we have here a derious regression no matter what we choose to do, because non-latin hotkeys were usable in previous versions of Gnome. But I also think that users of apps like Eclipse and JetBrains are programmers who rarely have to use non-latin languages, while users of LibreOffice use these languages all the time and are more dependant on them.

This is why I think that until a solution is found, these patches should be used across the board. If they are problematic, maybe it makes more sense to enable them for the PPA's only, and not in the stable version.

[silver_slice (silver-slice)]

Artur, I have the same bug with this ppa - in JetBrains phpStorm hotkeys now work only in non-latin keyboard layout. I installed ppa on clean Ubuntu 14.04.

[Denis Safronenkov (denis-safronenkov)]

i've got same problem on new installed ubuntu 14.04 and rubymine 6.3 with russian layout hotkeys
this helped and now both layouts works fine
https://gist.github.com/d3ZoRg/3f71ee24b1a0a288ce27

[Artur Eshenbrener (strate)]

Denis, tried your solution, not helped for me. Hotkeys works only in RU layout (checked in phpStorm and pyCharm)

[Tural Gurbanov (tgurbanov)]

Check once again. This solution doesn't work for me too.
Denis, how did you install java on your pc? Did you build it from sources or use something like ppa:webupd8team/java ?

[Nazar Mokrynskyi (nazar-pc)]

As I see here - bug is going to be fixed for every separate application which is completely wrong approach.
THIS IS THE MOST CRITICAL BUG since 13.10, and should be fixed for all apps in one place.
Users do not care how it works internally, we only know that regular Ctrl+C do not work with any non-latin layout.

[Nazar Mokrynskyi (nazar-pc)]

Awesome news! I found fix for this.
1) Disable of gnome control over keyboard:
gsettings set org.gnome.settings-daemon.plugins.keyboard active false
2) Set desired settings for xkb:
setxkbmap -option grp:rctrl_toggle,lv3:menu_switch us,ru,ua
You can add this to autostart
Here I switch layout with Right Control, Menu key is used for third level of keys and I use three layouts: English, Russian and Ukrainian.

One notice: keyboard indicator on panel lives in parallel reality in such setup, so I'm using gXneur to indicate current layout (only this, and disabled input monitoring, looks like gXneur is broken in Ubuntu 13.10-14.04 with GNOME and Unity) and disabled original one in keyboard settings.

As the result - I have all possible shortcuts working on any layout, switching layout with one key - right ctrl (not possible otherwise in GNOME) and separate layouts per windows and keyboard indicator with gXneur.

Yes, such ugly but perfectly working hacks because of "smart" decisions of GNOME developers.

[Artur Eshenbrener (strate)]

Nazar, you are my hero now! Really working solution, thank you.
But I can not use gxneur to indicate layout, because tray also broken in 14.04 ))
Also, do you know how to increase key repeating speed?

I am really can not understand, why unity/gnome developers trying to write their own keyboard switcher, instead of using xkb.

[Artur Eshenbrener (strate)]

For me bug also fixed when I just set desired settings to xkb:

setxkbmap -option grp:rctrl_toggle,lv3:menu_switch us,ru,ua

without disabling standard gnome switcher. So, gnome switcher switches keyboard layout indicator, xkb switches real layout.

[Nazar Mokrynskyi (nazar-pc)]

Actually they live in parallel realities, so switching of layout and indicator are in sync only if you use the same layout in all windows (I don't).

As for gXneur:
1) Run gXneur with
gxneur -E AppIndicator
Then go to settings and press "Save" to make this icon rendering engine permanent - should work fine
2) Enable manual switching on first tab of settings
3) Troubleshooting -> Tracking input -> Monitor the input
Uncheck this too to avoid duplication of printed symbols and similar bugs.

gXneur do not work properly, but as layout indicator it works fine.

[CrashIt (nadrshin)]

Nazar Mokrynskyi, thank you, it works!

[Abdolkarim Behravan (a-k-behravan)]

I use Ubuntu 13.10
I use two keyboar layout : English and Persian !
In english layout, keyboard shortcuts work fine but in Persian layout they don't work!
for example I can copy by (Ctrl+c) in english, but in persian I can't!

[Artur Eshenbrener (strate)]

Abdolkarim, try this: https://bugs.launchpad.net/unity/+bug/1226962/comments/221

[Michael Soluyanov (crantisz)]

Method of Nazar Mokrynskyi (nazar-pc) works well, but language swiching dosen't work in console (ctrl+alt+F1-F7)

[Nazar Mokrynskyi (nazar-pc)]

I think it works only under X, that is why the name setxkbmap from X keyboard.

[Norbert (nrbrtx)]

@Nazar and @Michael
You can try to set keyboard in terminals with
    sudo dpkg-reconfigure keyboard-configuration

As far I can remember 13.10 and 14.04 have /etc/default/keyboard config (see bug 1242572 for details).

[Lior Kaplan (kaplan)]

The problem still occurs with LibO 4.2.5 on Debian unstable (Gnome 3), but doesn't on 4.2.5 on Ubuntu 10.04 (Official DEBs, not from distro) with Gnome 2.30. Can anyone confirm/deny on KDE/qt so we could narrow this to Gnome 3?

[defis (stef-farad)]

1. Ubuntu 14.04, clean installed
2. English (US) + Greek
3. (Left) LShift + (Left) LAlt
4. Unity
5. Blender v2.7

When I use English keyboard layout I can use all the shortcuts (except some that use the Alt key, but that's a Linux problem. For example Alt + (Middle) MClick (or button 3)). But When I switch to Greek, I can use only the numeric shortcut (Ctlr + 1 for example).

[yh1000 (yechiam-halevy)]

This helped me in a couple of installations:

Confirm Ubuntu 14.04 with latest updates.

This helps me:

sudo add-apt-repository ppa:attente/java-non-latin-shortcuts
sudo apt-get update
sudo apt-get dist-upgrade
and then "restart unity-settings-daemon"

On Tue, Jun 24, 2014 at 8:03 AM, defis <email address hidden> wrote:

> 1. Ubuntu 14.04, clean installed
> 2. English (US) + Greek
> 3. (Left) LShift + (Left) LAlt
> 4. Unity
> 5. Blender v2.7
>
> When I use English keyboard layout I can use all the shortcuts (except
> some that use the Alt key, but that's a Linux problem. For example Alt
> + (Middle) MClick (or button 3)). But When I switch to Greek, I can use
> only the numeric shortcut (Ctlr + 1 for example).
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout in 13.10 and 14.04
>
> Status in Aptana Studio Installer:
> New
> Status in Default settings for the Baltix GNU/Linux OS and desktop:
> New
> Status in LibreOffice Productivity Suite:
> Confirmed
> Status in IBus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Inkscape: A Vector Drawing Tool:
> New
> Status in Mutter:
> Fix Released
> Status in The OpenOffice.org Suite:
> New
> Status in Unity:
> Fix Released
> Status in “gnome-settings-daemon” package in Ubuntu:
> Triaged
> Status in “gnome-terminal” package in Ubuntu:
> Triaged
> Status in “indicator-keyboard” package in Ubuntu:
> Triaged
> Status in “openjdk-7” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> Triaged
> Status in “unity-settings-daemon” package in Ubuntu:
> Triaged
> Status in “gnome-settings-daemon” package in Fedora:
> Unknown
> Status in “gnome-shell” package in Fedora:
> Unknown
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
>
> Dear Ubuntu users and developers!
> Please include the following information to your comment about non-latin
> shortcuts problems:
> 1. What Ubuntu version do you have (Ubuntu 13.10, Ubuntu 13.10 GNOME,
> Ubuntu 14.04, Ubuntu 14.04 GNOME and so on), upgraded (describe version) or
> clean installed
> 2. What keyboard layout do you have
> 3. What shortcut for keyboard layout switching do you use
> 4. On which session you have problems - th...

[Ayala Shani (shani-ayala)]

I can confirm yh1000 approach has solved it for me too:

sudo add-apt-repository ppa:attente/java-non-latin-shortcuts
sudo apt-get update
sudo apt-get dist-upgrade
and then "restart unity-settings-daemon"

I think I'll stick with this version (14.04) of Ubuntu for a long time now without upgrading...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Yannis (orions-belts1)]

Same config as #231, #234 steps seems to fix the problem. :)
 At least until the next update... !

[Shvets Jan (shvets-jan)]

Fix doesn't fix anything. If app was started with russian layout - hotkeys doesn't work, even change layout to english. I use 14.04 with newest updates, and problem still exist now (2014/07/28). Only solution for now is to start all apps with english layout or keep different layouts for every app with english as default.

[Vasil Yakauleu (vasilbelarus)]

Ubuntu 14.04.1 + latest updates
Still reproducible: after changing layout to russian shortcuts are not working.

[WhiteWind (temkaveter)]

Ubuntu 14.04 + all updates
Same bug is still here everywhere!
After installing
sudo add-apt-repository ppa:attente/java-non-latin-shortcuts
I have the other bug in Inkscape - hotkeys are working only in russian layout. Very annoying!

Is there any bulletproof solution? Any kind of drums/dances and chants/mantras?

[efanchik (efanchik)]

Patch for fix problem with non-latin keyboard in JetBrains products
"https://github.com/zheludkovm/LinuxJavaFixes"

[eliash (elia-shreidler)]

I tested that on Arch (Anteragos), with gnome 3.12
Build ID: 4.2.5.2 Arch Linux build-1

The bug still exists..

(I can test on ubuntu 12.04 if needed as well)

[Vstuart-foote (vstuart-foote)]

Version detail should be set to the earliest release the issue is confirmed on, please do not advance it--a note in a comment is all that is required.

Resetting to original reporting.

[Kpeace1-4 (kpeace1-4)]

Confirming that this bug STILL exists in:

$ uname -a
Linux localhost.localdomain 3.14.5-200.fc20.x86_64 #1 SMP Mon Jun 2 14:26:34 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/fedora-release
FXorg -version

X.Org X Server 1.14.4
Release Date: 2013-10-31
X Protocol Version 11, Revision 0
Build Operating System: 3.14.3-200.fc20.x86_64
Current Operating System: Linux localhost.localdomain 3.14.5-200.fc20.x86_64 #1 SMP Mon Jun 2 14:26:34 UTC 2014 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.5-200.fc20.x86_64 root=UUID=64bb5aa4-a945-4e0e-8d4d-776f44302cd1 ro rootflags=subvol=root vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8
Build Date: 27 June 2014 01:35:28AM
Build ID: xorg-x11-server 1.14.4-11.fc20
Current version of pixman: 0.30.0
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.edora release 20 (Heisenbug)

$ libreoffice --version
LibreOffice 4.2.6.2 420(Build:2)

Tools -> Options -> Language Settings -> Languages -> Ignore system input language - Checked as advised by commenter Paulo Fino, still no hotkeys :-(

[Norbert (nrbrtx)]

It's great that Ubuntu 14.10 MATE beta is not affected by this bug.

[Ivan Larionov (xeron-oskom)]

14.10 is affected. Super+A/F/M/C/V don't work in russian layout.

[Eli Mitrani (eli-mit-g)]

I am using Hebrew layout on Ubuntu 14.04 and Ubuntu Gnome 14.04. The bug exists on both. The only workaround I found was to change the Hebrew layout to Hebrew Lyx. This solves the problem of shortcuts, which is great!

However it introduces a new minor problem:
In the normal Hebrew layout pressing Shift or Caps Lock allows writing characters in uppercase English - this is very convenient when you want to add only several English words to a sentence.
In Hebrew Lyx pressing the Shift Key gives punctuation characters.

[Norbert (nrbrtx)]

@xeron-oskom (comment 245)
about Super+A/F/M/C/V please write comment to bug 1280759.

[Sam (sam-redhat-bugs)]

This bug appears to still exist in Fedora 20 with Gnome 3. Tested with Hebrew.

Try adding a new Hebrew keyboard layout, opening apps like Caligra, Kate, LibreOffice, and using Keyboard shortcuts like copy and paste.

For the KDE apps, could this be due to using an unpatched version of Qt where related bugs still exist? What is the likely cause in LibreOffice? Independent of this bug? https://www.libreoffice.org/bugzilla/show_bug.cgi?id=41169

Also related: https://bugs.launchpad.net/unity/+bug/1226962

[Yuval Adam (yuv-adm)]

This bug exists in a fully-updated Arch system:

$ uname -a
Linux XXXXX 3.17.3-1-ARCH #1 SMP PREEMPT Fri Nov 14 23:13:48 CET 2014 x86_64 GNU/Linux

$ libreoffice --version
LibreOffice 4.3.4.1 430m0(Build:1)

Please fix this annoying bug, it prevents non-English locale users from getting any meaningful work done.

[Barta-c (barta-c)]

moving this bug to mab4.3 list since 4.2.x is END OF LIFE

[Roman Shipovskij (roman-shipovskij)]

Bug still present in java programs on 14.04.

[Roman Shipovskij (roman-shipovskij)]

This bug present in Metacity (GNOME Flashback (Metacity)), for example Alt+Ctrl+T not working in non-latin keyboard layout, but working in Compiz (GNOME Flashback (Compiz))

[sergey (zwezda-11)]

Ubuntu 14.04
uname -a
Linux Vostro-1220 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:44 UTC 2014 i686 i686 i686 GNU/Linux

Hotkeys not functional in cyrillic keyboard for the some applications.
LibreOffice
OpenOffice
KeepassX
Gimp
and others
Not correctly the java functions work.
I wait for correction more than 6 months.
How many still to wait?

[Kendy-m (kendy-m)]

This bugreport got non-actionable in the meantime I am afraid; we should close it as per comment 33, because fixes of 2 problems were already provided, and also the information about the "Ignore system input language" seems to be helpful.

If there are still trouble with the shortcuts, please file that as separate report, and provide the following information:

* your locale / language settings
* your desktop environment, and its version
* LibreOffice version
* try also with the latest LibreOffice 'fresh' version, and tell if it is still
  present there
* if it is affected by Tools -> Options -> Language Settings -> Languages
  -> Ignore system input language
* exact reproduction steps (in the affected locale)

Thank you all for the reports and fixes!

[Fedora (fedora-redhat-bugs)]

This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Alexander (alexander-redhat-bugs)]

Still exists in Fedora 21. KDE apps (Konversation, Digikam, ..) don't respond to shortcuts, even in English keyboard layout when GNOME shell is in use.

[Ivan Larionov (xeron-oskom)]

Just updated to 15.04 and this bug is still exists.

[Kirill Kuzminykh (cykooz)]

Ubuntu 15.04
uname -a
Linux cykooz-pc 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Hotkeys not functional in cyrillic keyboard for the PyCharm 4.0.6 + Oracle Java 8 (from the webupd8team/java ppa)

[Alberto Salvia Novella (es20490446e)]

@ Dmitry "DeltaKilo" Korotkov

Why do you think this bug is affecting OpenJDK instead of its individual applications?

[ZoLToR (zoltor)]

All troubles because of unity-settings-daemon.
This patch helped me http://www.sisyphus.ru/ru/srpm/Sisyphus/gnome-settings-daemon/patches/0
I downloaded package source file, has made necessary manual replacement according to this patch, has built and installed package - all working fine!

[Ivan Larionov (xeron-oskom)]

This bug still exists in 15.10.

@zoltor thank you for the link, I'll give it a try.

[Ivan Larionov (xeron-oskom)]

So I've built new package with this patch here: https://launchpad.net/~xeron-oskom/+archive/ubuntu/unity-settings-daemon/

And it doesn't fix this problem with Super+A/F/M/C/V hotkeys in Unity.

BTW (offtopic warning) unity-settings-daemon package is in 1.0 format. Really? What year is it?

[Roman Shipovskij (roman-shipovskij)]

I use another patch, extracted from PPA in comment #182, and it works, but I only check it on Trusty.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "non-latin-shortcuts.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Alberto Salvia Novella (es20490446e)]

If you think this bug also exist in OpenJDK instead of its individual applications, please set its status to "confirmed".

[Alberto Salvia Novella (es20490446e)]

@ Ivan Larionov

If you find a bug exist in a particular release, please add its release first name into the tag list under the bug description.

[Ivan Larionov (xeron-oskom)]

@Alberto no offense, but for Unity this bug was never fixed, so you can easily add tag "all future Ubuntu releases". Bugs doesn't disappear if no one tries to fix it. And I assume that no one tries because it's 2 years old and affects a lot of people.

P.S. I'm talking about this parts of this bug: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1280759 (Super+A/F/M/C/V hotkeys).

[Ivan Larionov (xeron-oskom)]

@Roman thank you, your patch is working. At least it fixes Super+A/F/M/C/V.

Not sure about all other issues with openjdk/libreoffice/etc.

For people who want fixed version for vivid: https://launchpad.net/~xeron-oskom/+archive/ubuntu/unity-settings-daemon/

[ZoLToR (zoltor)]

I had made PPA for 14.04 Trusty with patched unity-ettings-daemon (patch from comment 258) - https://launchpad.net/~zoltor/+archive/ubuntu/unity-settings-daemon (maybe something wrong, this is my first PPA :D )

 @ Ivan Larionov, hm, I have no issues with Super+* hotkeys (I didn't applied Roman's patch from message 261). But I'm tested it on Trusty (x64) and you - on Vivid. Maybe this is important difference, don't know. Sometime appropriate lense opening not from first time when hot-key is pressed but this lag is exists both on an english and russian layouts for me :)

[Ivan Larionov (xeron-oskom)]

@zoltor I see issue with Super+A/F/M/C/V starting from 13.10 or 14.04 (don't remember). Some Super+* hotkeys are working, for example Super+W. Also this bug exists even if I boot from live USB so it's clearly not my user profile issue.

@Roman sadly but with your patch keyboard behavior is unpredictable. Sometimes it works well w/o this bug, but sometimes I can't even switch keyboard layout. Looks like sort of racing somewhere.

[Roman Shipovskij (roman-shipovskij)]

@ Ivan Larionov

We are using this patch on 15k+ machines with i386 Trusty and all works fine.

But we are using Ctrl/Alt+Shift for layout switching and GNOME Flashback (Metacity) on most computers.

[Ivan Larionov (xeron-oskom)]

@Roman that could be the difference since I'm on Vivid x64 and using Unity.

[William Hua (attente)]

Hi Roman, unfortunately the old patch breaks typing for users using Shift_L, Shift_R or Shift_L+Shift_R for layout switching, otherwise we would've merged it in a long time ago... I think we can only maintain it in a PPA. I'll update the old PPA again for the other releases too (Trusty through to Wily).

Thanks ZoLToR, but that other patch you linked to doesn't seem to fix the shortcuts problem in Inkscape or Eclipse from the Wily archive.

[William Hua (attente)]

Hi, could you guys try the PPA here? https://launchpad.net/~attente/+archive/ubuntu/java-non-latin-shortcuts

It just contains the old hack for Unity and GNOME Flashback users updated for Trusty/Vivid/Wily. Don't use this if your switching shortcut is left shift, right shift, or left+right shift.

[Ivan Larionov (xeron-oskom)]

@attente works on vivid with super+space switching.

[Norbert (nrbrtx)]

Bug exists in Ubuntu 15.10 beta2 - unable to start gnome-terminal in GNOME sessions on non-latin layout.

[OrDuek (orduek)]

attente -
Your PPA works great. I'm using alt+left Shift with no problems.
Thank you very much.

[Simos Xenitellis  (simosx)]

See http://www.whizzy.org/2015/09/big-bug-bonanza-16-04-lts/ for a sprint
to fix issues in Ubuntu (targeting 16.04).
Since there are patches for this and these patches work, it is important to
get the issue fixed during the sprint.

On Sat, Oct 10, 2015 at 10:49 AM, OrDuek <email address hidden> wrote:

> attente -
> Your PPA works great. I'm using alt+left Shift with no problems.
> Thank you very much.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout
>
> Status in aptana-studio-installer:
> New
> Status in Default settings and artwork for Baltix OS:
> New
> Status in LibreOffice Productivity Suite:
> Fix Released
> Status in ibus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Inkscape:
> New
> Status in monodevelop:
> New
> Status in mutter:
> Fix Released
> Status in okular:
> New
> Status in OpenOffice:
> New
> Status in sigram:
> New
> Status in Unity:
> Fix Released
> Status in gnome-settings-daemon package in Ubuntu:
> Triaged
> Status in gnome-terminal package in Ubuntu:
> Triaged
> Status in openjdk-7 package in Ubuntu:
> Incomplete
> Status in unity package in Ubuntu:
> Triaged
> Status in unity-settings-daemon package in Ubuntu:
> Triaged
> Status in gnome-shell package in Fedora:
> Unknown
> Status in openoffice package in Fedora:
> Unknown
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
>
> Dear Ubuntu users and developers!
> Please include the following information to your comment about non-latin
> shortcuts problems:
> 1. What Ubuntu version do you have (Ubuntu 13.10, Ubuntu 13.10 GNOME,
> Ubuntu 14.04, Ubuntu 14.04 GNOME and so on), upgraded (describe version) or
> clean installed
> 2. What keyboard layout do you have
> 3. What shortcut for keyboard layout switching do you use
> 4. On which session you have problems - that is one from Unity, GNOME
> Shell, GNOME FlashBack/Fallback (Metacity), GNOME FlashBack/Fallback
> (Compiz)
> 5. With which program and its version and origin (Ubuntu repositories,
> PPA, non-deb binary package from some website) you have problems.
>
> By providing this information you can make bug-fixing much simpler and
> may be faster.
>
> ----------
> For other ...

[Ivan Larionov (xeron-oskom)]

Actually @attente 's patch has issue with layout switching and hotkeys as well. On vivid sometimes after login all hotkeys don't work and you can't even switch layout. After relog it usually works again.

[Norbert (nrbrtx)]

Bug exists in Ubuntu 15.10 for example in at least Midnight Commander (mc) and gnome-terminal with Cyrillic (Russian) layout and en_US.UTF-8 locale.

[suslikk (suslikkreal)]

Bug exists in Ubuntu 15.10 for example in Josm (Java application) and Terminator terminal with Cyrillic (Russian) layout and en_US.UTF-8 locale.
!!!

[William Hua (attente)]

Hi, I have updated the PPA, please try the PPA:

https://launchpad.net/~attente/+archive/ubuntu/java-non-latin-shortcuts

[suslikk (suslikkreal)]

William Hua (attente), its work with Josm and GPSPrune. Thanks!

[Ari (aryehtanz)]

Fantastic!

How do you get it to work with apacheoffice?
thx

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 21 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Alexander (alexander-redhat-bugs)]

Still valid for Fedora 23.

[Oryganum (altclava)]

William Hua (attente), the last version of unity-settings-daemon (14.04.0+14.04.20151122-0ubuntu1ppa1) solved all my problems.
OmegaT and LibreOffice now understand short-cuts on both non-Latin languages I use.
Thank you very much!

[daphcnualdaphcnualdaphcnual (ewigekrieg)]

I confirm,
the update to unity-settings-daemon 14.04.0+14.04.20151122-0ubuntu1ppa1 did solved the issues for me too.

Hotkeys didn't work in Russian layout in ThinkingRock and Freemind (both are using Java), but now everything is fine.

The author(s) of the new version, you're the greatest dudes/gals in the universe! I love you!!

[Rick1 (khandramay)]

William Hua (attente) thanks. It's work for Intellij Idea 15

[Nazar Mokrynskyi (nazar-pc)]

Dear Ubuntu developers, FIX THIS ISSUE, please!
It is ridiculously stupid that every single application should do something special to support hotkeys, it should just work out of the box as it forked for many years before. I've tired to explain to many people how to get rid of unity-settings-daemon plugin and use setxkbmap instead!

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-settings-daemon - 15.04.1+16.04.20160119-0ubuntu1

---------------
unity-settings-daemon (15.04.1+16.04.20160119-0ubuntu1) xenial; urgency=medium

  [ William Hua ]
  * plugins/keyboard/gsd-keyboard-manager.c:
    - Fix shortcuts for non-latin keyboard layouts in certain programs,
      but only when the user's layout switching shortcuts are not
      Shift_L, Shift_R, <Shift>Shift_L, or <Shift>Shift_R (LP: #1226962)

  [ Rui Matos ]
  * power: Fix a crash when reading invalid backlight values

  [ Sebastien Bacher ]
  * keyboard: Avoid warning when bell-custom-file changes

 -- Iain Lane <email address hidden> Tue, 19 Jan 2016 17:08:48 +0000

[Norbert (nrbrtx)]

Dear Launchpad Janitor (janitor)!

I'm sorry but users need this bug to fixed completely in all supported Ubuntu releases.
By all supported releases I mean especially LTS - 12.04 LTS, 14.04 LTS, 16.04 LTS.

Please fix this annoying bug completely without PPAs and other crutches.
Thank you!

[Iain Lane (laney)]

I am reverting this patch, it broke keyboard shortcuts for me in terminator, so it will have to be revisited.

[suslikk (suslikkreal)]

Confirm on Ubuntu 16.04 in JOSM (Openstreetmap editor). HOT KEYS DON'T work in Russian layout!!!

[eNdiD (endid13)]

Confirm on Ubuntu 14.04, 14.10, 15.04, 15.10 releases with latin and cyrillic layouts. System hotkeys works ok (terminal hotkey e.g.).
But IDE's hotkeys (Sublime Text, PhpStorm, Intellij Idea) makes me suffer.
Well.. Someone. Fix it. Please.

[Norbert (nrbrtx)]

Bug still exists in 14.04 and 16.04.

[Konstantinas Tarchanovas (konstantinast)]

> Confirm on Ubuntu 14.04, 14.10, 15.04, 15.10 releases with latin and cyrillic layouts. System hotkeys works ok (terminal hotkey e.g.).
But IDE's hotkeys (Sublime Text, PhpStorm, Intellij Idea) makes me suffer.
Well.. Someone. Fix it. Please.

I second that, because for me in Ubuntu 14.04.4 LTS, Intellij Idea with Netbeans keymap (long-story :D) keyboard shortcut CTRL + SHIFT + 1 (non numpad) only gets captured by Intellij Idea when Ubuntu keyboard language is set to "EN", but when I switch to my native language "LT" (Lithuanian), then nothing happens nowhere :)

[Izhar (yimprogramming)]

I have this bug also on Ubuntu 14.04, on Libre (at the system generally not) .

I have download the latest Libre release yesterday, 5.1.0, but it's doesn't solved.

Is there is any solution?
<email address hidden>

[Dmitry Veltishev (vdmit)]

Same issue on 15.10, Unity desktop.
In most applications (except Firefox) shortcuts like Ctrl+F not working in alternate (Russian in my case) layout.

[Alexandr (jumpjet68)]

Confirm this bug on ubuntu 16.04 (updated 2016.03.12) with unity-settings-daemon 15.04.1+16.04.20160209
System hotkeys work ok, java-based IDE (Sublime Text, PhpStorm, Intellij Idea) hotkeys don't work.

[Ivan Larionov (xeron-oskom)]

Some system hotkeys are still broken. Super+A/F/M/C/V hotkeys do not work.

[n0dwis (n0dwis-u)]

On Cinnamon in Mine everything works fine, so bug in Gnome/Unity, I think.

[Alexandr (jumpjet68)]

Bug is still confirmed on Ubuntu 16.04, but this ppa https://launchpad.net/~attente/+archive/ubuntu/java-non-latin-shortcuts repaired it. Why patch is still not in the official repository?

[Alexandr (jumpjet68)]

P.S. Many thanks to William Hua.

[Ivan Larionov (xeron-oskom)]

Alexandr, this PPA breaks layout switch for some systems.

See comments:

https://bugs.launchpad.net/unity/+bug/1226962/comments/277
https://bugs.launchpad.net/unity/+bug/1226962/comments/289

[Alexandr (jumpjet68)]

I found one more bug in that PPA. When i use english keyboard layout, slash key (dot-period key in russian layout) works as it have to, but Ctrl+slash hotkey gives me Ctrl+[dot+period] keyboard shortcut in PyCharm and Intellij IDEA as though i've used russian layout.

[Alexandr (jumpjet68)]

One another bug is that russian layout with Caps Lock activated behaves as english layout with Caps Lock, and vice versa. Tested PyCharm and Intellij IDEA, other applications works well.

[Alexandr (jumpjet68)]

same shit in Firefox and LibreOffice.

[Pe4enko (ipe4enko)]

Same issue on 16.04, Java applications, Intellij Idea

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ari (aryehtanz)]

Please fix openoffice.

This was fixed once and came back. Could be done much better.

On Tue, Jul 12, 2016 at 12:43 AM, Norbert <email address hidden>
wrote:

> ** Tags added: yakkety
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout
>
> Status in aptana-studio-installer:
> New
> Status in Default settings and artwork for Baltix OS:
> New
> Status in LibreOffice:
> Fix Released
> Status in ibus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Inkscape:
> New
> Status in Intellij Idea:
> New
> Status in monodevelop:
> New
> Status in mutter:
> Fix Released
> Status in okular:
> New
> Status in OpenOffice:
> New
> Status in sigram:
> New
> Status in Unity:
> Fix Released
> Status in gnome-settings-daemon package in Ubuntu:
> Triaged
> Status in gnome-terminal package in Ubuntu:
> Triaged
> Status in kdevelop package in Ubuntu:
> Confirmed
> Status in openjdk-7 package in Ubuntu:
> Incomplete
> Status in unity package in Ubuntu:
> Fix Released
> Status in unity-settings-daemon package in Ubuntu:
> In Progress
> Status in gnome-settings-daemon source package in Xenial:
> Triaged
> Status in gnome-terminal source package in Xenial:
> Triaged
> Status in kdevelop source package in Xenial:
> Confirmed
> Status in openjdk-7 source package in Xenial:
> Incomplete
> Status in unity source package in Xenial:
> Fix Released
> Status in unity-settings-daemon source package in Xenial:
> In Progress
> Status in gnome-shell package in Fedora:
> Unknown
> Status in openoffice package in Fedora:
> Unknown
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
>
> Dear Ubuntu users and developers!
> Please include the following information to your comment about non-latin
> shortcuts problems:
> 1. What Ubuntu version do you have (Ubuntu 13.10, Ubuntu 13.10 GNOME,
> Ubuntu 14.04, Ubuntu 14.04 GNOME and so on), upgraded (describe version) or
> clean installed
> 2. What keyboard layout do you have
> 3. What shortcut for keyboard layout switching do you use
> 4. On which session you have problems - that is one from Unity, GNOME
> Shell, GNOME FlashBack/Fallback (Metacity), GNOME FlashBack/Fallback
> (Compiz)
> 5. With wh...

[Ivan Larionov (xeron-oskom)]

So 16.10 released with the same bug.

I assume this won't be fixed until they release Ubuntu with Unity 8 because it uses QT and won't be affected by this bug :)

[Arutyun (arutyun-akopov)]

The same problem in NetBeans IDE 8.2

[referee (referee-home)]

ubuntu 16.10
same issue, intellij idea, datagrip
use english and russian layout, ctrl+shift to switch between them

[ZoLToR (zoltor)]

Just use another keyboard switcher (e.g., gxkb) and keep only one English layout in system layout switcher. I tried gxkb and all worked fine but some another issues appeared, which specific to gxkb (e.g., when laptop was waking up from the sleep mode, gxkb settings were resetting. Also, I didn't see gxkb indicator on the lock screen, so sometime I entered the password on wrong layout). But I almost didn't notice this gxkb-specific issues in comparison with this idiotic annoying issue in unity-settings-daemon, which cannot be fixed so long time (wtf? Developers are fixing the result of this issue by adding some "bicycles" to software where this issue is persist, but they aren't fixing the ROOT CAUSE in unity-setting-daemon -_-" )

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 23 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Fedora (fedora-redhat-bugs)]

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Ivan Larionov (xeron-oskom)]

The same bug affects 17.04.

Apparently it will be fixed only after migration to Gnome :)

[Igor Shuvalov (i-s-shuvalov)]

Please, try to make EN first layout in 'Region & Language' settings

[Nazar Mokrynskyi (nazar-pc)]

My first language is EN, doens't help.
Migration FROM GNOME will help, because GNOME stack is the root cause of this issue.

[ZoLToR (zoltor)]

As I remember, I couldn't recreate this issue in Gnome (but to be honest, I'm not sure for 100% :) ). So, I assume, that the issue caused by Canonical's developers, who made the changes in unity-settings-daemon (which initially was forked from gnome-settings-daemon).

[Nazar Mokrynskyi (nazar-pc)]

It happened in gnome-settings-daemon first and then appeared in u-s-d, so this is GNOME-specific issue.

[Ivan Larionov (xeron-oskom)]

It has nothing to do with GNOME. This is unity-settings-daemon bug.

Unity-settings-daemon is outdated fork of gnome-settings-daemon. Now, because Gnome Team maintains their stack and fixes issues this exact bug doesn't exist in Gnome, but unity-settings-daemon is outdated and was never updated from Gnome's upstream (which is probably very hard because of huge amount of Ubuntu/Unity changes in this package) so this bug was never fixed in Unity stack.

[Nazar Mokrynskyi (nazar-pc)]

When was it fixed in GNOME? I was using gnome-settings-daemon's keyboard handling till ~3.18 and it didn't work since the moment they break it. I do not want to reconfigure system right now, but I'm pretty sure it wasn't fixed, just various GNOME apps were patched with workarounds, while generally issue is still there and it seems like will never be fixed at all.

[Simos Xenitellis  (simosx)]

I think this report needs to clear up. The title and the description should get an update.

I am using stock Ubuntu 16.04.2 (i.e. Unity 7) and I have configured two keyboard layouts, EN, GR.

I start gedit and I press the Ctrl+S (Save) hotkey.
In both cases (Layouts: EN (English), GR (Greek)), the Save dialog box appears.
Similarly, I tested with Firefox, Chrome and Chromium and it worked as well (Ctrl+τ to open a new tab).

Therefore, it is working for me at least for these apps.

Is there anyone that cannot get this to work on Ubuntu 16.04?
If so, tell me what keyboard layouts you have enabled.
Note that the first keyboard layout MUST be "En" (English).

[Nazar Mokrynskyi (nazar-pc)]

@simosx take any Java app or an app that didn't add workarounds (Gedit was one of the first where it was fixed) and use Ctrl+C on Cyrillic layout (Ukrainian as an example). I wouldn't work even on 17.04. So yes, there are apps (many of them listed in this issue) that kind of fixed it, but the root cause is the GNOME stack and it was not fixed and even not going to be fixed ever (I can't find relevant upstream issue right now, but it was closed as not a bug).

[Simos Xenitellis  (simosx)]

@nazar-pc: Java GUI apps on Linux is a special case. Firstly, they are no such apps pre-installed, so it is somewhat a non-Ubuntu problem.

Gedit is written in the C programming language and is part of the core GNOME apps. It is well-support and shortcuts work. It has been working for 10+ years, since the multi-layout shortcut support was added to GTK+.

This ability to use shortcuts even when the active layout was not English, was added to GTK+ (GNOME) at around 2005, perhaps earlier. It was the first UI toolkit to have such support for shortcuts when the active layout was not English. Qt did not have it for a long long time (has it been added there?).

I am inclined to close this report in a few days if we do not get a reproducible case of shortcuts not working.
At the same time, I'll open (if they do not exist) individual reports regarding shortcuts in Java GUI apps and other toolkits that do not have that support.

[Ivan Larionov (xeron-oskom)]

> we do not get a reproducible case of shortcuts not working

Seriously?

Try Unity hotkeys in Russian layout: (cmd+a/f/m/c/v).

[Simos Xenitellis  (simosx)]

@xeron-oskom: The Unity 7 shortcuts are adapted accordingly when the keyboard layout is switched to Greek. See screenshot below.
When you keep pressed the Win key, you get that information text with all shortcuts.

Admittedly, I just checked that a few shortcuts are not adapted for Greek so they require specific bug reports. However, the general functionality is there.
Can you check what is shown in my screenshot, but for Russian?

This bug report has reached 325 comments. Any developer would struggle to make sense as it is now.

[Nazar Mokrynskyi (nazar-pc)]

@simosx, I do not care what the hell is going on, I just know that Java-based and some other apps (can't recall the list right now) simply do not work like you say they are. They work on Windows and they work under X11 when I set languages with setxkbmap (for the last few years I use setxkbmap + gxkb for tray information about current layout exactly because of this issue, see https://bugs.launchpad.net/unity/+bug/1226962/comments/221).

With setxkbmap everything just works perfectly in ANY APP I ever encounter. Which apparently means g-s-d or u-s-d or whatever will come with the next GNOME release (probably will be moved to Mutter as everything else these days) is the root cause of the issue. And GNOME should be fixed, not every app in this universe.

[Ivan Larionov (xeron-oskom)]

simosx, Super+A/F/M/C/V are not adapted and do not work in Russian Layout. I even tried Greek and they do not work in Greek as well.

Another example is Ctrl+Q. Open unity-control-center and try Ctrl+Q in English and Greek. In Greek it won't work. In English it will close and app.

[Simos Xenitellis  (simosx)]

@nazar-pc: It is very important to care and make an effort to figure out what is going on.
Your case is about Java apps, which is a distinctive group of GUI programs.
I am not aware of functionality that XIM ('setxkbmap') would offer the feature to have working shortcuts with non-English layouts, unless it is some hack that is specific to the Java app.

For your case, I highly recommend for you to create a new bug report under "java-common",
https://launchpad.net/ubuntu/+source/java-common
with a title like "Shortcuts/hotkeys not working when non-latin layout is active",
and describe in detail the problem and add your workaround using "setxkbmap".

Then, post the URL of the report here so that those that are interested, can subscribe as well.
I'll then look to find the appropriate upstream project and link there.

[Simos Xenitellis  (simosx)]

@xeron-oskom: Indeed, Super+A/F/M/C/V are not adapted and do not currently work with Greek either.
However, what is working, are those shortcuts that I show in my screenshot (Super+W, Super+S).

Here is a screenshot that shows that when you switch to Russian keyboard layout, the Unity shortcuts for Super+W and Super+S are adapted automatically for Russian.

The way that Super+W and Super+S work, makes me believe that these are not hard-coded but dynamic.
Here is relevant code http://bazaar.launchpad.net/~unity-team/unity/trunk/files/head:/shortcuts/

[drorlev (dror-sign)]

LibreOffice shortcuts don't work in Hebrew on Ubuntu 16.04

On Fri, Apr 21, 2017 at 12:19 PM, Simos Xenitellis  <
<email address hidden>> wrote:

> @xeron-oskom: Indeed, Super+A/F/M/C/V are not adapted and do not currently
> work with Greek either.
> However, what is working, are those shortcuts that I show in my screenshot
> (Super+W, Super+S).
>
> Here is a screenshot that shows that when you switch to Russian keyboard
> layout, the Unity shortcuts for Super+W and Super+S are adapted
> automatically for Russian.
>
> The way that Super+W and Super+S work, makes me believe that these are not
> hard-coded but dynamic.
> Here is relevant code http://bazaar.launchpad.net/~
> unity-team/unity/trunk/files/head:/shortcuts/
>
>
> ** Attachment added: "unity-shortcuts-russian.png"
> https://bugs.launchpad.net/unity/+bug/1226962/+
> attachment/4865983/+files/unity-shortcuts-russian.png
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1246583).
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout
>
> Status in aptana-studio-installer:
> New
> Status in Default settings and artwork for Baltix OS:
> New
> Status in LibreOffice:
> Fix Released
> Status in ibus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Inkscape:
> New
> Status in Intellij Idea:
> New
> Status in monodevelop:
> New
> Status in Mutter:
> Fix Released
> Status in okular:
> New
> Status in OpenOffice:
> New
> Status in sigram:
> New
> Status in Unity:
> Fix Released
> Status in gnome-settings-daemon package in Ubuntu:
> Triaged
> Status in gnome-terminal package in Ubuntu:
> Triaged
> Status in kdevelop package in Ubuntu:
> Confirmed
> Status in openjdk-7 package in Ubuntu:
> Incomplete
> Status in unity package in Ubuntu:
> Fix Released
> Status in unity-settings-daemon package in Ubuntu:
> In Progress
> Status in gnome-settings-daemon source package in Xenial:
> Triaged
> Status in gnome-terminal source package in Xenial:
> Triaged
> Status in kdevelop source package in Xenial:
> Confirmed
> Status in openjdk-7 source package in Xenial:
> Incomplete
> Status in unity source package in Xenial:
> Fix Released
> Status in unity-settings-daemon source package in Xenial:
> In Progress
> Status in gnome-shell package in Fedora:
> Unknown
> Status in openoffice package in Fedora:
> Unknown
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey ...

[Simos Xenitellis  (simosx)]

@dror-sign: I just tried the Alt+F shortcut on LibreOffice, on Ubuntu 16.04, having enabled the Hebrew keyboard layout. It worked for me.

You are supposed to have as primary keyboard layout the English (En) keyboard layout.

[drorlev (dror-sign)]

Alt+... shortcuts work fine :-)

Ctrl+... shortcuts don't work :-(

On Fri, Apr 21, 2017 at 7:00 PM, Simos Xenitellis  <
<email address hidden>> wrote:

> @dror-sign: I just tried the Alt+F shortcut on LibreOffice, on Ubuntu
> 16.04, having enabled the Hebrew keyboard layout. It worked for me.
>
> You are supposed to have as primary keyboard layout the English (En)
> keyboard layout.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1246583).
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Hotkeys not functional in non-latin keyboard layout
>
> Status in aptana-studio-installer:
> New
> Status in Default settings and artwork for Baltix OS:
> New
> Status in LibreOffice:
> Fix Released
> Status in ibus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Inkscape:
> New
> Status in Intellij Idea:
> New
> Status in monodevelop:
> New
> Status in Mutter:
> Fix Released
> Status in okular:
> New
> Status in OpenOffice:
> New
> Status in sigram:
> New
> Status in Unity:
> Fix Released
> Status in gnome-settings-daemon package in Ubuntu:
> Triaged
> Status in gnome-terminal package in Ubuntu:
> Triaged
> Status in kdevelop package in Ubuntu:
> Confirmed
> Status in openjdk-7 package in Ubuntu:
> Incomplete
> Status in unity package in Ubuntu:
> Fix Released
> Status in unity-settings-daemon package in Ubuntu:
> In Progress
> Status in gnome-settings-daemon source package in Xenial:
> Triaged
> Status in gnome-terminal source package in Xenial:
> Triaged
> Status in kdevelop source package in Xenial:
> Confirmed
> Status in openjdk-7 source package in Xenial:
> Incomplete
> Status in unity source package in Xenial:
> Fix Released
> Status in unity-settings-daemon source package in Xenial:
> In Progress
> Status in gnome-shell package in Fedora:
> Unknown
> Status in openoffice package in Fedora:
> Unknown
>
> Bug description:
> New keyboard layout changer in Ubuntu 13.10 introduce old-new bug. Any
> system or application hotkey witch use char (for example: ctrl+alt+t for
> terminal or ctrl+t for new tab in browser) become unfunctional when
> selected non-latin keyboard layout.
> Hotkeys with F1-12, numbers and other non-character buttons works
> perfectly.
>
> Window manager hotkeys not affected by this bug. All hotkeys in system
> parameters->keyboard->hotkeys->windows works perfect with any keyboard
> layout.
>
> Workaround for some system hotkeys and two layouts (english and non-
> latin): rebind all hotkeys in your local layout. For example instead
> of ctrl+alt+t use ctrl+alt+τ (greek tau). That hotkey still work with
> english layout. If you use english and two different non-latin
> layouts this workaround helps only with one of them.
>
>
> Dear Ubuntu users and developers!
> Please include the following information to your comment about non-latin
> shortcuts problems:
> 1. What Ubuntu version do you have (Ubuntu 13.10, Ubuntu 13.10 GNOME,
> Ubuntu 14.04, Ubuntu 14.04 GNOME and so on), upgraded (describe version) or
> clean installed
> 2. What keyboard layout do you have
> 3. What s...

[Simos Xenitellis  (simosx)]

@dror-sign: I have tested with Ctrl+O (File→Open...).
Indeed, when they keyboard layout is in Hebrew, Ctrl+O in Libreoffice does not work.
However, Ctrl+O in LibreOffice for at least Greek and Russian works.

Therefore, this inability for Ctrl+... shortcuts not working in LibreOffice for Hebrew is an issue by itself, that is specific to Hebrew (and needs a new report that is specific to Hebrew and other layouts that are affected in the same way).

[Norbert (nrbrtx)]

Unity shortcuts (Super+A/F/M/C/V) do not work on non-latin layout in Xenial.
I use English and Russian layouts.

[Simos Xenitellis  (simosx)]

@nrbrtx: As noted in #329, the shortcuts for Super+A/F/M/C/V indeed do not work on Unity.

However, the shortcuts for Super+S/W actually work. This means that the functionality is there to make Super+A/F/M/C/V work as well. See the screenshot at #329 that demonstrates that Russian is OK for Super+S/W.

[Harel Mazor (harelm)]

When using Hebrew keyboard, key shortcut are completely unavailable - not even the simple things like CTRL+C to copy.
I couldn't understand what was not working as the scenario is as follow:
Create a text box, switch to Hebrew to write something in Hebrew - forgot that I change the language - no keyboard shortcut are available... :-(

[Norbert (nrbrtx)]

On Ubuntu Xenial with MATE, Russian and English layouts:
+ Inkscape works normally;
+ LibreOffice works normally;
- Midnight Commander does not react to <F9+с+а> (<F9+c+f> on Russian layout).

[Norbert (nrbrtx)]

On Ubuntu Artful 17.10 with new "Unity"(gnome-shell extension) on Wayland; Russian and English layouts:
+ Inkscape works normally;
+ in new Dash <Super+D> works;
+ LibreOffice works normally;
+ <Ctrl+A>,<Ctrl+C>,<Ctrl+V> work;
- in new Dash <Super+A>, <Super+S>, <Super+H>, <Super+L>, <Super+V>, <Super+M> do not work on Russian layout.
- Midnight Commander does not react to <F9+с+а> (<F9+c+f> on Russian layout).

[Norbert (nrbrtx)]

On Ubuntu Artful 17.10 with new "Unity"(gnome-shell extension) on X11; Russian and English layouts:
+ Inkscape works normally;
+ LibreOffice works normally;
+ <Ctrl+A>,<Ctrl+C>,<Ctrl+V> work;
- in new Dash <Super+A>, <Super+D>, <Super+S>, <Super+H>, <Super+L>, <Super+V>, <Super+M> do not work on Russian layout.
- Midnight Commander does not react to <F9+с+а> (<F9+c+f> on Russian layout).

[Norbert (nrbrtx)]

On Ubuntu Artful 17.10 in GNOME session on Wayland; Russian and English layouts:
+ Inkscape works normally;
+ LibreOffice works normally;
+ <Ctrl+A>,<Ctrl+C>,<Ctrl+V> work;
- in new Dash <Super+A>, <Super+D>, <Super+S>, <Super+H>, <Super+V>, <Super+M> do not work on Russian layout.
- Midnight Commander does not react to <F9+с+а> (<F9+c+f> on Russian layout).

[Norbert (nrbrtx)]

On Ubuntu Artful 17.10 in GNOME session on X11; Russian and English layouts:
+ Inkscape works normally;
+ LibreOffice works normally;
+ <Ctrl+A>,<Ctrl+C>,<Ctrl+V> work;
- in new Dash <Super+A>, <Super+D>, <Super+S>, <Super+H>, <Super+V>, <Super+L>, <Super+M> do not work on Russian layout.
- Midnight Commander does not react to <F9+с+а> (<F9+c+f> on Russian layout).

[Norbert (nrbrtx)]

On Ubuntu Artful 17.10 in GNOME Classic on X11; Russian and English layouts:
+ Inkscape works normally;
+ LibreOffice works normally;
+ <Ctrl+A>,<Ctrl+C>,<Ctrl+V> work;
- <Ctrl+Alt+T> does not open terminal on Russian layout;
- in new Dash <Super+A>, <Super+D>, <Super+S>, <Super+H>, <Super+V>, <Super+L>, <Super+M> do not work on Russian layout.
- Midnight Commander does not react to <F9+с+а> (<F9+c+f> on Russian layout).

[Norbert (nrbrtx)]

IMHO below:
So it is again unbelievable. GNOME became big buggy hipster's crap.
I'll recommend to use MATE Desktop Environment everywhere when it is possible.

[Leagnus (petra8)]

PPA attente/java-non-latin-shortcuts fixed problem in a java app
in Ubuntu 16.04.3 LTS (Unity) for Russian language.
William Hua saved my day.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Patrick Storz (ede123)]

Should be mostly fixed in current 0.92.x branch of Inkscape.

Related commits:
https://gitlab.com/inkscape/inkscape/commit/e5d477fa2df049ea731d2a0809ebd6fe03f660d6
https://gitlab.com/inkscape/inkscape/commit/8221730a84375f91b4f791bbad8b7b6d9547cdd8

Any remaining issues should be tracked in more targeted bugs.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[krama (kramaphone)]

Thanks!

сб, 12 мая 2018 г., 6:00 Bryce Harrington <email address hidden>:

> ** Changed in: inkscape
> Status: Fix Committed => Fix Released
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1226962
>
> Title:
> Keyboard shortcuts (hotkeys) not functional in some cases in non-latin
> keyboard layouts
>
> Status in aptana-studio-installer:
> New
> Status in Default settings and artwork for Baltix OS:
> New
> Status in LibreOffice:
> Fix Released
> Status in ibus:
> New
> Status in Indicator keyboard:
> Fix Released
> Status in Inkscape:
> Fix Released
> Status in Intellij Idea:
> New
> Status in monodevelop:
> New
> Status in Mutter:
> Fix Released
> Status in okular:
> New
> Status in OpenOffice:
> New
> Status in sigram:
> New
> Status in Unity:
> Fix Released
> Status in gnome-settings-daemon package in Ubuntu:
> Triaged
> Status in gnome-terminal package in Ubuntu:
> Triaged
> Status in kdevelop package in Ubuntu:
> Confirmed
> Status in mc package in Ubuntu:
> Confirmed
> Status in openjdk-7 package in Ubuntu:
> Incomplete
> Status in terminator package in Ubuntu:
> Confirmed
> Status in unity package in Ubuntu:
> Fix Released
> Status in unity-settings-daemon package in Ubuntu:
> In Progress
> Status in gnome-settings-daemon source package in Xenial:
> Triaged
> Status in gnome-terminal source package in Xenial:
> Triaged
> Status in kdevelop source package in Xenial:
> Confirmed
> Status in mc source package in Xenial:
> Confirmed
> Status in openjdk-7 source package in Xenial:
> Incomplete
> Status in terminator source package in Xenial:
> Confirmed
> Status in unity source package in Xenial:
> Fix Released
> Status in unity-settings-daemon source package in Xenial:
> In Progress
> Status in gnome-shell package in Fedora:
> Won't Fix
> Status in openoffice package in Fedora:
> Won't Fix
>
> Bug description:
> Keyboard shortcuts are key combinations like Alt+F (usually opens the
> File menu) and Ctrl+O (usually opens the File→Open... dialog box).
>
> There is an issue with non-latin keyboard layouts that the keys under F
> or O (for Alt+F and Ctrl+O respectively) would correspond to some other
> character.
> What should happen then? There is some smart functionality (at least in
> the GTK+ library) that when we press a shortcut, it will try to make Alt+F
> or Ctrl+O work, even if the active keyboard layout is not English.
>
> For this smart functionality to work, it requires us to have as first
> keyboard layout the English (en) layout. Then, GTK+ will be able to
> check whether the shortcut makes sense for English, and if so, will run
> it.
> All that even if the active layout is Greek or Russian or something
> else.
>
> This report has over 300 comments and these comments include all sort of
> corner cases that indeed shortcuts do not work. In general, shortcuts work,
> but in specific cases there are issues that need to be fixed.
>
> What we need to do, is collect those corner cases and create new
> separate reports.
>
> Here are the corner cases:
>
> 1. ...

[Jean- (jean-helou)]

I was referred here by Gunnar Hjalmarsson following a question on askubuntu [1] regarding incorrect layout for hotkeys in at least intellij idea and vscode.

In both cases, hotkeys seem to be pinned to the layout corresponding to the first input source declared in the gnome Language and Region settings.
For shortcuts ( and for shortcuts only which makes it really painful) the layout doesn't change but normal typing is correctly remapped.

I have read through this thread but am still unsure if the issue is
- in ubuntu/gnome/linux
- in the apps themselves
- in my own configuration

What I observe :
- setup an azerty layout then a qwerty layout (both are latin compatible)
- in azerty text typing and hotkeys behave as expected in vscode and intellij
- in qwerty text typing behaves correctly but hotkeys are still mapped to the physical keys they would be bound to in the azerty layout
- reverse azerty and qwerty in gnome settings
- in qwerty text typing and hotkeys behave as expected in vscode and intellij
- in azerty text typing behaves correctly but hotkeys are still mapped to the physical keys they
would be bound to in the qwerty layout

What I expect :
- setup an azerty layout then a qwerty layout (both are latin compatible)
- in azerty text typing and hotkeys are bound to azerty keys both in vscode and intellij
- in qwerty text typing and hotkeys are bound to qwerty keys both in vscode and intellij
- reverse azerty and qwerty in gnome settings
- in azerty text typing and hotkeys are bound to azerty keys both in vscode and intellij
- in qwerty text typing and hotkeys are bound to qwerty keys both in vscode and intellij

I tried various combinations of configurations at various layers to try and make this work to no avail for now. my latest config state is in the askubuntu post

[1] https://askubuntu.com/questions/1281251/keyboard-shortcuts-do-not-honor-selected-input-source-in-some-apps

[Jean- (jean-helou)]

intellij can be "fixed" by enabling Settings -> Keymap -> Use National layouts for shortcuts
see https://youtrack.jetbrains.com/issue/IDEA-254960

I can't say I understand all the implications here maybe there are good reasons for it but having different commands report different layout in a single user system is really confusing.