Hotkeys not functional in non-latin keyboard layout in 13.10 and 14.04

Reported by Misha Bazanov on 2013-09-18
This bug affects 266 people
Affects Status Importance Assigned to Milestone
Indicator keyboard
Critical
William Hua
Inkscape
Undecided
Unassigned
LibreOffice Productivity Suite
Confirmed
Critical
OpenOffice
New
Undecided
Unassigned
Unity
High
Unassigned
ibus
New
Undecided
Unassigned
mutter
Fix Released
Medium
gnome-settings-daemon (Fedora)
Unknown
Unknown
gnome-settings-daemon (Ubuntu)
High
Unassigned
gnome-terminal (Ubuntu)
High
Unassigned
indicator-keyboard (Ubuntu)
High
Unassigned
unity (Ubuntu)
High
Unassigned
unity-settings-daemon (Ubuntu)
High
Unassigned

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

Stephen M. Webb (bregma) on 2013-09-18
Changed in unity:
importance: Undecided → High
status: New → Triaged
Changed in unity (Ubuntu):
status: New → Triaged
importance: Undecided → High

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-) wrote :

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

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

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

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.

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.

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
Nik.Th. (nick-athens30) 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 168 comments
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.

Nik.Th. (nick-athens30) 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.

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.

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.

Lars Uebernickel (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?

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.

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

@ 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-) wrote :

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

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.

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.

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

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

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

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

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
Launchpad Janitor (janitor) wrote :

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

Changed in indicator-keyboard (Ubuntu):
status: New → Confirmed
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
Evgecyn (evgecyn) 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.

Igor Zubarev (igor.zubarev) wrote :

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

Misha Bazanov (bmw-) wrote :

@Igor This bug is not relative, try #1218322

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

I confirm that the bug still remains

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

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) on 2013-10-29
description: updated
Norbert (nrbrtx) on 2013-10-31
tags: added: keyboard-layout-switching-related
Charles Kerr (charlesk) on 2013-11-03
Changed in indicator-keyboard:
assignee: nobody → William Hua (attente)
status: Fix Committed → Fix Released
88 comments hidden view all 168 comments

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

Changed in gnome-control-center:
importance: Unknown → Medium
status: Unknown → Invalid
Norbert (nrbrtx) on 2013-11-19
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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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) on 2013-12-15
Changed in df-libreoffice:
importance: Undecided → Unknown
status: New → Unknown
Changed in df-libreoffice:
importance: Unknown → Critical
status: Unknown → Invalid

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.

tags: added: trusty

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) wrote :

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.

Norbert (nrbrtx) on 2013-12-24
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
Majed Aly (majed-aly) wrote :

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 !

maria (gina-g-gg23) on 2014-01-22
Changed in gnome-settings-daemon (Ubuntu):
status: Triaged → In Progress
1 comments hidden view all 168 comments

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) wrote :

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!

William Hua (attente) on 2014-02-04
tags: added: ubuntu-desktop-trusty
Saveliy Tretiakov (st-t) wrote :

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?

William Hua (attente) on 2014-02-05
Changed in unity:
status: Invalid → In Progress

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) wrote :

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

Changed in unity:
status: In Progress → Fix Committed
2 comments hidden view all 168 comments

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

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

2 comments hidden view all 168 comments
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu):
status: New → Confirmed
Launchpad Janitor (janitor) wrote :
Download full text (18.5 KiB)

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

Changed in unity (Ubuntu):
status: Confirmed → Fix Released
Changed in df-libreoffice:
status: Invalid → Confirmed
2 comments hidden view all 168 comments
Launchpad Janitor (janitor) wrote :

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

Changed in unity-settings-daemon (Ubuntu):
status: New → Fix Released
Changed in mutter:
status: New → Fix Released
Ivan Larionov (xeron-oskom) wrote :

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

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.

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 Pourmoosa (amirmasoud) wrote :

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

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) wrote :

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.

tags: added: trusty-desktop
Norbert (nrbrtx) wrote :

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

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
Nazar Mokrynskyi (nazar-pc) wrote :

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

Stephen M. Webb (bregma) on 2014-04-03
Changed in unity:
status: Fix Committed → Fix Released
Norbert (nrbrtx) wrote :

@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) wrote :

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

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

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

Norbert (nrbrtx) wrote :

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

On netbeans 7.2.1 java 1.6.0_31 hotkeys works only on non-latin layout

Displaying first 40 and last 40 comments. View all 168 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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