Severe regressions to typing in Greek, Russian, etc due to IBus

Bug #1228422 reported by Simos Xenitellis 
124
This bug affects 27 people
Affects Status Importance Assigned to Milestone
Unity
New
Undecided
Unassigned
unity (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

For the last several versions of Ubuntu, there was an inability to type Greek (or many non-latin scripts) in the Dash.
With bug https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1205713 the problem has been fixed, and it got fixed by enabling IBus for Greek, Russian and several other scripts.

However, this change revealed several deficiencies in IBus (tested with Greek and Russian):

1. It is no longer possible to use keyboard accelerators when the active keyboard layout is in Greek, Russian, etc.
The reason is because the gtk+ IM contains special code so that Ctrl+A while in the Greek keyboard layout would still do a "Select All".
Currently in Ubuntu 13.10, when you press, for example, Ctrl+A (with Greek layout active), the app receives a Greek Alpha, which is ignored by the app.

The same goes with, for example, Alt+F, which no longer opens up the File menu.

More background about this at https://bugzilla.mozilla.org/show_bug.cgi?id=69230#c2
(FIXME: need to add link to gtk+ git with code on how they implement the solution)

2. The default keyboard shortcut to switch between keyboard layouts is Super+Space (default for IBus). Pressing the Super key ends up bringing up the HUD most of the times. I have been trying to get myself to press Super+Space more properly, but it's really difficult to get it right. I now get it right only about 30% of the times, and I need to pause when typing in order to check if I am actually writing by accident in the HUD.

I would say it is a huge usability issue that, as is, will alienate non-English users of Ubuntu.

3. It is not possible to change the shortcut to switch keyboard layouts to the traditional Alt+Shift (used by most Ubuntu-gr users).
In addition, if you manage to change the shortcut to something else, then it's impossible to change back to Super+Space.

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

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

Changed in unity (Ubuntu):
status: New → Confirmed
Revision history for this message
George Christofis (geochr) wrote :

Maybe there is a conflict with the bug: https://bugs.launchpad.net/nux/2.0/+bug/1205713
The developers might helped from the history of the previous bug, the changes and fixes on it.

affects: unity (Ubuntu) → ubuntu
affects: ubuntu → unity (Ubuntu)
Revision history for this message
Jeremy Bícha (jbicha) wrote :

Thanks for your bug report and helping to make Ubuntu better.

The Mozilla bug report isn't really useful though as it's over 12 years old.

Changed in unity:
assignee: nobody → George Macris (ubuderix)
description: updated
Changed in unity:
assignee: George Macris (ubuderix) → nobody
Revision history for this message
Brandon Schaefer (brandontschaefer) wrote :

Thank you for submitting this bug. Overall we have seen this problem and are actively looking for the correct solution. I've written about it here:

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

So far, there was never a real solution (or so it seems) and it seemed work only by a bug that was fixed recently in the keyboard layout changer, though I need to triple check this :).

As for problems you listed at 2&3, those are a bit different problems and should be their own bugs :).

Thank you again.

Revision history for this message
Filippos Kolyvas (fkol-k4) wrote :
Download full text (3.2 KiB)

I have done some testing using different applications and different input mode settings on Ubuntu Saucy, and i notice that there are some differences concerning keyboard shortcuts, depending on the application used. Long story short, while on LibreOffice and Chromium Browser we can see a stable behavior regardless of the input mode used, Gedit seems to be reacting differently to some actions.
I am attaching a screenshot of an analysis table for these tests, in hope that this will be helpful to the dev team. If more testing is needed, i 'll be glad to help out.

On the matter that if the layout shortcut changes then it cannot be reverted back to default, i saw that when trying to set the layout shortcut back to Super+Space in the Text Entry Settings window, then the input is read as Mod4+Super+Hyper+Space, so one cannot revert to default any more. But when trying the exact same thing through System Settings > Keyboard > Shortcuts > Typing, then the Super+Space shortcut is read correctly and the user can revert to default. Maybe there are some differences between the two setting modes?

So that leaves the matter of the available layout changing shortcut. Please, let me explain briefly why this is so important.
In many non-English documents, we can find a lot of words written in English, such as technological terms, names, brands, product model names, and even measurement units. This is not a problem for a non-English speaking but user as long as the user's language uses the latin alphabet. That is because at this case, English characters are a subset of the user's native layout. For example, a French user can type any English word using the French layout.
This is not the case for Greek or Cyrillic alphabet language users, as no Latin characters are part of the Greek or Cyrillic layout. This means that in a single page of document, one may need to change layouts up to 100 times (50 from native to Latin and 50 back to native). That gets even worst when shortcuts like cut/copy/paste do not work in native layout, so additional layout changes must be made.
So, it is clear that something that is used so often, should be as convenient as possible. That means thta the layout changing shortcut should:
- Be enabled by just one hand (ideally the left one, as the right hand controls the <Enter>, <Backspace>, etc).
- Contain as less keys as possible (preferably just one, two at the most), that are located close to each other.
This sets a limit to the lower left side of the keyboard. The Alt+Shift is not considered an ideal solution, but due to its long time usage from a widows user, is achieved relatively easy. Even better alternative solutions, are the Ctrl+Shift shortcuts (offered also as an alternative on Windows), and plain Caps Lock key (available also in Windows machines via AutoHotKey application). I am referring to windows because a lot of users are dual booting, or even use windows machines in work environments, so there should be some compatibility of something used so much.

My sincere apologies for the length of my comment and for pointing out things that may be obvious, my intention was just to make sure that a point haw been made about why t...

Read more...

To post a comment you must log in.
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.