always set "xkb,us" despite set of other layout when input-sources is empty

Bug #1514544 reported by Mitsuya Shibata
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
unity-settings-daemon (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

When input-sources is empty, unity-settings-daemon try to fill
input-sources/sources by DEFAULT_LAYOUT at get_sources_from_xkb_config().

Please use DEFAULT_LAYOUT only when doesn't other keyboard layout.

How to reproduce:

1. set xkb layout other than us layout
$ setxkbmap -layout jp

2. clear settings
$ gsettings set org.gnome.desktop.input-sources sources "@as []"

3. restart unity-settings-daemon
$ systemctl --user restart unity-settings-daemon.servic

Expected result:
xkb,jp layout and input method settings
$ gsettings get org.gnome.desktop.input-sources sources
[('xkb', 'jp'), ('fcitx', 'mozc')]

Actual result:
xkb,us is always inserted.
$ gsettings get org.gnome.desktop.input-sources sources
[('xkb', 'jp'), ('xkb', 'us'), ('ibus', 'anthy')]

Related branches

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

I sent merge proposal. please review it.

Changed in unity-settings-daemon (Ubuntu):
status: New → In Progress
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, I think ("xkb", "us") is always inserted because it's needed to have keybinding to working cross layouts (e.g ctrl-C doing copy even if you are using "jp")

Changed in unity-settings-daemon (Ubuntu):
importance: Undecided → Low
Revision history for this message
William Hua (attente) wrote :

Yes, Sebastien is right, we have to keep it in the list of XKB layouts for keyboard shortcuts in non-latin layouts. It looks like the bug is more related to the migration process.

Can you please tell us what files are in your ~/.local/share/unity-settings-daemon/ directory?

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

Sebastien and William,

Ah, I understand. Thank you for your clarification.

Anyway, do I have a chance to drop "(xkb,us)" when layouts has specific layout like "ja"?

For example, japanese layout has completely alphabet keys as same as "us" layout.
Therefore japanese layout user doesn't need "us" layout for shortcuts and other operations.
If input-sources has "us" layout, user confuses key layout when layout switching (super+space).

- [('xkb','ja'), ('fcitx','mozc')]

  User can switch layout between xkb/ja (use direct input) and fcitx/mozc (use IME).

- [('xkb','ja'), ('xkb', 'us'), ('fcitx','mozc')]

  User needs twice "spuer+space" to switch from xkb/ja to fcitx/mozc.

My goal is dropping xkb/us from *default* settings for japanese locale.
Adding code which drop DEFAULT_LAYOUT if layouts has "ja" is acceptable?
Or should I do this out of unity-settings-daemon?

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

> Can you please tell us what files are in your ~/.local/share/unity-settings-daemon/ directory?

Following is wily:

$ ls -l ~/.local/share/unity-settings-daemon/
-rw-rw-r-- 1 shibata shibata 0 Nov 11 02:20 fcitx-engines-migrated
-rw-rw-r-- 1 shibata shibata 0 Nov 11 02:20 input-sources-converted

Above contents is same as following environment where boot up from wily installer.
Environment 1. Select "Japanese" and "Try ubuntu without install" in gfxboot.
Environment 2. No select gfxboot, then set "Japanese" and select "Try Ubuntu" in ubiquity.

description: updated
Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

Hi Sebastien and William,

After a long time, finally, I made new patch and sent merge request.

Based on the advice pointed out by Sebastien, all locale except "ja_JP", add "us" layout as default keyboard layout. "ja_JP" locale (and added locale to locale_layout array) use layout variable in locale_layout array as default keyboard layout.

Could you review it?

Changed in unity-settings-daemon (Ubuntu):
status: In Progress → Confirmed
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.