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

Bug #1226962 reported by Misha Bazanov
This bug affects 491 people
Affects Status Importance Assigned to Milestone
Default settings and artwork for Baltix OS
New
Undecided
Unassigned
Indicator keyboard
Fix Released
Critical
William Hua
Inkscape
Fix Released
Undecided
Unassigned
Intellij Idea
New
Undecided
Unassigned
LibreOffice
Fix Released
Critical
Mutter
Fix Released
Medium
OpenOffice
New
Undecided
Unassigned
Unity
Fix Released
High
Unassigned
Visual Studio Code
New
Undecided
Unassigned
aptana-studio-installer
New
Undecided
Unassigned
ibus
New
Undecided
Unassigned
monodevelop
New
Undecided
Unassigned
okular
New
Undecided
Unassigned
sigram
New
Undecided
Unassigned
gnome-settings-daemon (Ubuntu)
Triaged
High
Unassigned
Xenial
Triaged
High
Unassigned
gnome-shell (Fedora)
Won't Fix
Medium
gnome-terminal (Ubuntu)
Triaged
High
Unassigned
Xenial
Triaged
High
Unassigned
kdevelop (Ubuntu)
Confirmed
High
Unassigned
Xenial
Confirmed
High
Unassigned
mc (Ubuntu)
Confirmed
Undecided
Unassigned
Xenial
Confirmed
Undecided
Unassigned
openoffice (Fedora)
Won't Fix
Medium
terminator (Ubuntu)
Confirmed
Undecided
Unassigned
Xenial
Confirmed
Undecided
Unassigned
unity (Ubuntu)
Fix Released
High
Unassigned
Xenial
Fix Released
High
Unassigned
unity-settings-daemon (Ubuntu)
In Progress
High
William Hua
Xenial
In Progress
High
William Hua

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. 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>

Related branches

Revision history for this message
In , Leonid (leonid-redhat-bugs) wrote :

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.

Revision history for this message
In , Caolan (caolan-redhat-bugs) wrote :

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

Revision history for this message
In , Leonid (leonid-redhat-bugs) wrote :

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 :(

2 comments hidden view all 366 comments
Revision history for this message
In , Alex (alex-redhat-bugs) wrote :

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.

Stephen M. Webb (bregma)
Changed in unity:
importance: Undecided → High
status: New → Triaged
Changed in unity (Ubuntu):
status: New → Triaged
importance: Undecided → High
350 comments hidden view all 366 comments
Revision history for this message
Brandon Schaefer (brandontschaefer) wrote :

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...

Revision history for this message
Misha Bazanov (bmw-) wrote :

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

Revision history for this message
Brandon Schaefer (brandontschaefer) wrote :

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.

Revision history for this message
Misha Bazanov (bmw-) wrote :

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).

Revision history for this message
Brandon Schaefer (brandontschaefer) wrote :

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!

Revision history for this message
George Christofis (geochr) wrote :

@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?

Revision history for this message
Simos Xenitellis  (simosx) wrote :

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.

Revision history for this message
Simos Xenitellis  (simosx) wrote :

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.

Revision history for this message
Stephen M. Webb (bregma) wrote :

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.

Changed in indicator-keyboard:
importance: Undecided → Critical
status: New → Triaged
Changed in indicator-keyboard (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in unity (Ubuntu):
status: Triaged → Invalid
Changed in unity:
status: Triaged → Invalid
Revision history for this message
N1ck 7h0m4d4k15 (nicktux) wrote :

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.

1 comments hidden view all 366 comments
Revision history for this message
Stephen M. Webb (bregma) wrote :

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

Revision history for this message
N1ck 7h0m4d4k15 (nicktux) wrote :

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.

Revision history for this message
William Hua (attente) wrote :

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.

Revision history for this message
Stephen M. Webb (bregma) wrote :

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.

Revision history for this message
Lars Karlitski (larsu) wrote :

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?

Revision history for this message
Stephen M. Webb (bregma) 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.

Revision history for this message
Simos Xenitellis  (simosx) wrote : Re: [Bug 1226962] Re: Hotkeys not functional in non-latin keyboard layout

@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.

no longer affects: unity (Ubuntu)
Revision history for this message
Filippos Kolyvas (fkol-k4) wrote : Re: Hotkeys not functional in non-latin keyboard layout

@ 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?

Revision history for this message
Misha Bazanov (bmw-) wrote :

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

Revision history for this message
Simos Xenitellis  (simosx) wrote :

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

Revision history for this message
Artyom Kazak (artyom-kazak) wrote :

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.

Revision history for this message
Simos Xenitellis  (simosx) wrote :

@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.

summary: - Hotkeys not functional in non-latin keyboard layout
+ Hotkeys not functional in non-latin keyboard layout in 13.10
Revision history for this message
Dmitry Shachnev (mitya57) wrote : Re: Hotkeys not functional in non-latin keyboard layout in 13.10

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.

affects: indicator-keyboard (Ubuntu) → gnome-settings-daemon (Ubuntu)
Revision history for this message
Filippos Kolyvas (fkol-k4) 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.

Revision history for this message
Dmitry Shachnev (mitya57) wrote : Re: [Bug 1226962] Re: Hotkeys not functional in non-latin keyboard layout in 13.10

@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
>

Revision history for this message
Filippos Kolyvas (fkol-k4) wrote : Re: Hotkeys not functional in non-latin keyboard layout in 13.10

@ 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

Revision history for this message
Jacob Popov (j-a-popov) wrote :

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. :-(

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in indicator-keyboard:
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in indicator-keyboard (Ubuntu):
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in indicator-keyboard (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Evgecyn (evgecyn-deactivatedaccount) wrote :

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.

Revision history for this message
Igor Zubarev (igor.zubarev) wrote :

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

Revision history for this message
Misha Bazanov (bmw-) wrote :

@Igor This bug is not relative, try #1218322

Revision history for this message
Roman Vorobets (roman-vorobets) wrote :

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.

Revision history for this message
Gilad Ravid (gilad-m) wrote :

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

Revision history for this message
Andreas Tsourouflis (andreas-tsourouflis) wrote :

I confirm that the bug still remains

Revision history for this message
Andreas Tsourouflis (andreas-tsourouflis) wrote :

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.

Revision history for this message
Filippos Kolyvas (fkol-k4) wrote :

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.

Revision history for this message
Norbert (nrbrtx) wrote :

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).

tags: added: saucy
Norbert (nrbrtx)
description: updated
Norbert (nrbrtx)
tags: added: keyboard-layout-switching-related
Charles Kerr (charlesk)
Changed in indicator-keyboard:
assignee: nobody → William Hua (attente)
status: Fix Committed → Fix Released
Changed in gnome-control-center:
importance: Unknown → Medium
status: Unknown → Invalid
Norbert (nrbrtx)
Changed in gnome-control-center:
importance: Medium → Unknown
status: Invalid → Unknown
affects: gnome-control-center → mutter
Changed in mutter:
importance: Unknown → Medium
status: Unknown → New
John Rotomano (rotomano)
Changed in df-libreoffice:
importance: Undecided → Unknown
status: New → Unknown
Changed in df-libreoffice:
importance: Unknown → Critical
status: Unknown → Invalid
Norbert (nrbrtx)
tags: added: trusty
309 comments hidden view all 366 comments
Revision history for this message
In , Nrbrtx (nrbrtx-redhat-bugs) wrote :

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

2 comments hidden view all 366 comments
Revision history for this message
In , Nrbrtx (nrbrtx-redhat-bugs) wrote :

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

Norbert (nrbrtx)
summary: - Hotkeys not functional in non-latin keyboard layout in 13.10
+ Hotkeys not functional in non-latin keyboard layout
summary: - Hotkeys not functional in non-latin keyboard layout
+ Hotkeys not functional in non-latin keyboard layout in 13.10 and 14.04
1 comments hidden view all 366 comments
Revision history for this message
In , Nrbrtx (nrbrtx-redhat-bugs) wrote :

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

maria (gina-g-gg23)
Changed in gnome-settings-daemon (Ubuntu):
status: Triaged → In Progress
William Hua (attente)
tags: added: ubuntu-desktop-trusty
William Hua (attente)
Changed in unity:
status: Invalid → In Progress
Changed in unity:
status: In Progress → Fix Committed
Changed in unity (Ubuntu):
status: New → Confirmed
Changed in unity (Ubuntu):
status: Confirmed → Fix Released
Changed in df-libreoffice:
status: Invalid → Confirmed
Changed in unity-settings-daemon (Ubuntu):
status: New → Fix Released
Changed in mutter:
status: New → Fix Released
Norbert (nrbrtx)
tags: added: trusty-desktop
Changed in gnome-settings-daemon (Ubuntu):
milestone: none → ubuntu-14.04
Changed in indicator-keyboard (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-14.04
Changed in unity (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-14.04
Changed in unity-settings-daemon (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-14.04
Changed in gnome-settings-daemon (Ubuntu):
status: In Progress → Triaged
Changed in gnome-terminal (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-14.04
status: New → Triaged
Stephen M. Webb (bregma)
Changed in unity:
status: Fix Committed → Fix Released
Changed in unity (Ubuntu):
status: Fix Released → Triaged
Changed in unity-settings-daemon (Ubuntu):
status: Fix Released → Triaged
Changed in indicator-keyboard (Ubuntu):
status: Fix Released → Triaged
Changed in openjdk-7 (Ubuntu):
status: New → Confirmed
Changed in kingsoft-office (Ubuntu):
status: New → Confirmed
Norbert (nrbrtx)
description: updated
Norbert (nrbrtx)
tags: added: apport-collected
Changed in openjdk-7 (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
no longer affects: kingsoft-office (Ubuntu)
information type: Public → Public Security
information type: Public Security → Private Security
information type: Private Security → Public
Changed in sublime-text (Ubuntu):
status: New → Confirmed
no longer affects: sublime-text (Ubuntu)
summary: - Hotkeys not functional in non-latin keyboard layout in 13.10 and 14.04
+ Hotkeys not functional in non-latin keyboard layout in 13.10, 14.04,
+ 14.04.1
summary: Hotkeys not functional in non-latin keyboard layout in 13.10, 14.04,
- 14.04.1
+ 14.04.1, 14.10
2 comments hidden view all 366 comments
Revision history for this message
In , Sam (sam-redhat-bugs) wrote :

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

Changed in df-libreoffice:
status: Confirmed → Fix Released
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Mathew Hodson (mhodson)
tags: added: keyboard-layout-switching-hotkeys metabug
removed: charset hotkeys keyboard-layout-switching-related layout trusty-desktop
Mathew Hodson (mhodson)
tags: removed: ubuntu-desktop-trusty
Revision history for this message
In , Alexander (alexander-redhat-bugs) wrote :

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.

no longer affects: indicator-keyboard (Ubuntu)
tags: added: utopic
tags: added: vivid
summary: Hotkeys not functional in non-latin keyboard layout in 13.10, 14.04,
- 14.04.1, 14.10
+ 14.04.1, 14.10, 15.04
Changed in openjdk-7 (Ubuntu):
status: Triaged → Incomplete
summary: - Hotkeys not functional in non-latin keyboard layout in 13.10, 14.04,
- 14.04.1, 14.10, 15.04
+ Hotkeys not functional in non-latin keyboard layout
tags: added: patch
tags: added: wily
Mathew Hodson (mhodson)
Changed in gnome-settings-daemon (Ubuntu):
milestone: ubuntu-14.04 → none
affects: gnome-shell (Fedora) → ubuntu
Changed in ubuntu:
importance: Unknown → Undecided
status: Unknown → New
no longer affects: ubuntu
affects: gnome-settings-daemon (Fedora) → ubuntu
Changed in ubuntu:
importance: Unknown → Undecided
status: Unknown → New
no longer affects: ubuntu
Changed in gnome-terminal (Ubuntu):
milestone: ubuntu-14.04 → none
Mathew Hodson (mhodson)
Changed in unity (Ubuntu):
milestone: ubuntu-14.04 → none
Changed in unity-settings-daemon (Ubuntu):
milestone: ubuntu-14.04 → none
Will Cooke (willcooke)
tags: added: rls-w-incoming
tags: added: rls-x-incoming
removed: rls-w-incoming
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Revision history for this message
In , Alexander (alexander-redhat-bugs) wrote :

Still valid for Fedora 23.

Changed in unity (Ubuntu):
status: Triaged → Invalid
Will Cooke (willcooke)
tags: removed: rls-x-incoming
Changed in unity (Ubuntu):
status: Invalid → Fix Released
Changed in unity-settings-daemon (Ubuntu Xenial):
status: Triaged → Fix Released
Iain Lane (laney)
Changed in unity-settings-daemon (Ubuntu Xenial):
assignee: nobody → William Hua (attente)
status: Fix Released → In Progress
Norbert (nrbrtx)
tags: added: xenial
Changed in kdevelop (Ubuntu Xenial):
status: New → Confirmed
Changed in kdevelop (Ubuntu):
status: New → Confirmed
Changed in kdevelop (Ubuntu):
importance: Undecided → High
Changed in kdevelop (Ubuntu Xenial):
importance: Undecided → High
Norbert (nrbrtx)
tags: added: yakkety
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

tags: added: zesty
32 comments hidden view all 366 comments
Revision history for this message
Ivan Larionov (xeron-oskom) wrote : Re: Hotkeys not functional in non-latin keyboard layout

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.

Revision history for this message
Simos Xenitellis  (simosx) wrote :

@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.

Revision history for this message
Simos Xenitellis  (simosx) 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/

Revision history for this message
drorlev (dror-sign) wrote : Re: [Bug 1226962] Re: Hotkeys not functional in non-latin keyboard layout
Download full text (4.3 KiB)

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 ...

Read more...

Revision history for this message
Simos Xenitellis  (simosx) wrote : Re: Hotkeys not functional in non-latin keyboard layout

@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.

Revision history for this message
drorlev (dror-sign) wrote : Re: [Bug 1226962] Re: Hotkeys not functional in non-latin keyboard layout
Download full text (3.8 KiB)

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...

Read more...

Revision history for this message
Simos Xenitellis  (simosx) wrote : Re: Hotkeys not functional in non-latin keyboard layout

@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).

Revision history for this message
Norbert (nrbrtx) wrote :

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

Revision history for this message
Simos Xenitellis  (simosx) wrote :

@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.

description: updated
summary: - Hotkeys not functional in non-latin keyboard layout
+ Keyboard shortcuts (hotkeys) not functional in some cases in non-latin
+ keyboard layout
summary: Keyboard shortcuts (hotkeys) not functional in some cases in non-latin
- keyboard layout
+ keyboard layouts
Revision history for this message
Harel Mazor (harelm) wrote :

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... :-(

Revision history for this message
Norbert (nrbrtx) wrote :

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)
tags: added: artful
Revision history for this message
Norbert (nrbrtx) wrote :

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).

Revision history for this message
Norbert (nrbrtx) wrote :

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).

Revision history for this message
Norbert (nrbrtx) wrote :

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).

Revision history for this message
Norbert (nrbrtx) wrote :

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).

Revision history for this message
Norbert (nrbrtx) wrote :

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).

Revision history for this message
Norbert (nrbrtx) wrote :

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.

Revision history for this message
Leagnus (petra8) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in mc (Ubuntu Xenial):
status: New → Confirmed
Changed in mc (Ubuntu):
status: New → Confirmed
Changed in openoffice (Fedora):
importance: Unknown → Medium
status: Unknown → Won't Fix
Changed in gnome-shell (Fedora):
importance: Unknown → Medium
status: Unknown → Won't Fix
Norbert (nrbrtx)
tags: added: bionic
removed: saucy utopic vivid wily yakkety
15 comments hidden view all 366 comments
Revision history for this message
Patrick Storz (ede123) wrote :

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.

Changed in inkscape:
status: New → Fix Committed
milestone: none → 0.92.3
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in terminator (Ubuntu Xenial):
status: New → Confirmed
Changed in terminator (Ubuntu):
status: New → Confirmed
Bryce Harrington (bryce)
Changed in inkscape:
status: Fix Committed → Fix Released
1 comments hidden view all 366 comments
Revision history for this message
krama (kramaphone) wrote : Re: [Bug 1226962] Re: Keyboard shortcuts (hotkeys) not functional in some cases in non-latin keyboard layouts
Download full text (3.9 KiB)

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. ...

Read more...

Revision history for this message
Jean- (jean-helou) wrote :

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

no longer affects: openjdk-7 (Ubuntu Xenial)
no longer affects: openjdk-7 (Ubuntu)
Revision history for this message
Jean- (jean-helou) wrote :

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.

Norbert (nrbrtx)
tags: removed: artful trusty zesty
Displaying first 40 and last 40 comments. View all 366 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.