#26 proposal: IM and xkb UI design improvements
Closed: Fixed None Opened 6 years ago by petersen.

= phenomenon =
Currently in Fedora for languages with non-Latin scripts
we normally switch between a xkb layout as an input source
for inputting Latin/ASCII characters and an IME for
inputting native characters.

ibus-kkc and ibus-libpinyin both have Latin ("English") input methods.
I think it is more natural for primary users of these IMEs
to use them by default for Latin character input. So I want to
suggest that for F21 we could default Japanese input to use only the kkc IME
and Chinese to libpinyin IME, ie no additional keyboard layout source
would be needed. Multilingual users might still need an additional
keyboard layout input source and that is still fine. Other IMEs
might also be extended to support Latin input modes in the future:
initially we could do it for those default IMEs that support it.

For example I am already using ibus-kkc for both Latin and Japanese input
and it works well - I toggle easily between direct and ja input.

Perhaps the only change needed for the current IMEs with Latin mode
might be input mode state caching, ie using the same mode as last time.


Yeah, If Default IME's for langugae are capable of supporting latin input without any major problem. No need to keep XKB Latin ime enable on desktop.

might be improved in the future but one advantage to support this so far is, it would be faster to take effects. super+space on gnome-shell often takes some time to apply. just a note.

I try to summarize high level ideas from the discussions in the meetings so far:

http://meetbot.fedoraproject.org/fedora-meeting/2013-09-26/i18n.2013-09-26-06.05.log.html

  • Separate keyboard layouts vs maps and IMEs more precisely
  • Generically layout switching only makes sense for certain specific cases
  • either switching between different physical keyboards
  • or switching between keymaps compatible with a particular keyboard layout
  • one problem with new approach is consistency of hotkeys and how to be consistent for single and multiple IME cases
  • one solution/workaround might be not to define any IME switching hotkey by default perhaps
  • might be good if all IMEs providing non-Latin input also had a Latin mode (for Workstations)
  • input framework should couple IMEs with keyboard layouts (configurable)
  • should use meta-data about ascii/latin compatible xkb layouts (like langtable provides) to limit choices of layouts for IMEs

http://meetbot.fedoraproject.org/fedora-meeting/2013-10-03/i18n.2013-10-03-06.01.log.html

  • need to contact hangul upstream maintainer to ask if willing to add Latin mode to libhangul or ibus-hangul
  • need framework UI for assignment keyboard layout (map) for IME
  • need discussion with Gnome people about the design and UI experience
  • need panel status icon to show IME input mode
  • should discuss with Rui, Allan, etc

http://meetbot.fedoraproject.org/fedora-meeting/2013-10-10/i18n.2013-10-10-06.04.log.html

  • http://code.google.com/p/ibus/issues/detail?id=1662 (ibus request)
  • currently keyboard source shows what layout is being used by IME (kind of a hack though)
  • maybe IME label should show the configured layout if there is ambiguity "kkc (JP)" vs "kkc (US)" say instead
  • should we worry about multiple physical keyboard switching case?
  • problem/purpose
  • simpler UI
  • performance: faster switching within IME
  • more systematic layout handling
  • preserve IME input mode state (across sessions etc)
  • support for custom layouts

http://meetbot.fedoraproject.org/fedora-meeting/2013-10-23/i18n.2013-10-23-06.02.log.html#l-23

  • need to weigh pros and cons of having kbd input source by default with IME source
  • indicator should expand IME mode submenu by default, and be placed above IME list
  • for IMEs defaulting to Latin input, keyboard layout source is normally redundant
  • framework support for IME mode switching
  • maybe default IME mode should depend on whether have keyboard input source or not
  • fast mode switching might be useful for ibus-typing-booster too
  • maybe only default IMEs to Latin for new users without keyboard source (migration hard to do)
  • each ibus engine can inherit IBusEngineSimple for Latin mode
  • xkb is too much on the same level as IMEs
  • use "Super+space" for mode switching with single source?
  • ibus switching uses XI2 and anthy mode switching uses gdk keybinding which also works in nested VM box
  • https://bugzilla.gnome.org/show_bug.cgi?id=703779

http://meetbot.fedoraproject.org/fedora-meeting/2013-10-30/i18n.2013-10-30-06.01.log.html#l-49

  • mobile IMEs also tend to use mode switching
  • (some smart mobile keyboards support auto-detecting language)

http://meetbot.fedoraproject.org/fedora-meeting/2013-11-06/i18n.2013-11-06-06.03.log.html#l-95

Okay summarizing the previous discussions a bit:

== Goals
- simpler UI
- performance: faster switching within IME
- more systematic layout handling

== IME layout/maps
- keyboard layouts separate from maps and IMEs
- xkb too much on the same level as IMEs
- should use meta-data about ascii/latin compatible xkb layouts (like langtable provides) to limit choices of layouts for IMEs
- input framework (or IMEs?) should provide UI for configuring keyboard map per IME
- support for custom layouts

== Switching
- generically layout switching only makes sense for certain specific cases:
1. switching between different physical keyboards
2. switching between keymaps compatible with a particular keyboard layout
- maybe only define IME mode switching hotkey by default perhaps
- could use "Super+space" for mode switching with single source
- for IMEs defaulting to Latin input, keyboard layout source is normally redundant
- default to Latin if no other input sources defined (for Workstations)
- ibus switching uses XI2 and anthy mode switching uses gdk keybinding which also works in nested VM box

== IME Latin
- most IMEs providing non-Latin input should also have a Latin mode
- will hangul IME support Latin mode?
- need panel status icon to show IME input mode
- mobile IMEs also tend to use mode switching
- framework support for IME mode switching
- each ibus engine can inherit IBusEngineSimple for Latin mode

== UI defaults
- default IME mode may depend on whether there is a keyboard input source or not
- only default IMEs to Latin for new users without a keyboard source (migration hard to do)
- preserve IME input mode state across sessions: http://code.google.com/p/ibus/issues/detail?id=1662
- current keyboard source should not determine layout used by IME
- if there is ambiguity IME label could show the configured layout: eg "kkc (JP)" vs "kkc (US)"
- gnome-shell
- need discussion with Gnome people about the design and UI experience
- indicator should expand IME mode submenu by default, and be placed above IME list
- gnome-shell grabs Super-Space: https://bugzilla.gnome.org/show_bug.cgi?id=703779
- only show switcher when more than two input sources

After more discussions and consideration we may make this into a F21 Change proposal.

It will help to get more view on this topic from fedora-devel list.

I will try to open up some discussions on this soon.

After more direct discussions we came to the conclusion that currently
Latin mode (direct input) seems specific to Japanese IMEs alas.
Going with that reduces the potential scope of this proposal somewhat,
and might mean losing the display of IME input mode in the ibus applet.

= Revised Summary without Latin mode

== Goals
- simpler UI
- more systematic layout handling

== IME layout/maps
- keyboard layouts should be lower level than maps and IMEs
- currently xkb too much on the same level as IMEs
- should use meta-data about ascii/latin compatible xkb layouts (like langtable provides) to limit choices of layouts for IMEs
- input framework (or IMEs?) should provide UI for configuring keyboard map per IME

== Switching
- generically layout switching only makes sense for certain specific cases:
1. switching between different physical keyboards
2. switching between keymaps compatible with a particular keyboard layout
- ibus switching shortcut uses XI2 and anthy mode switching shortcut uses gdk keybinding which also works in nested VM

== IME modes
- might be nice if libpinyin provided a direct input Latin mode
- still seems attractive to default Japanese to use IME only and default to Latin mode
- RFE: option to show IME input mode in applet
- framework support for IME modes and switching
- ibus engines that don't provide Latin input can inherit IBusEngineSimple for Latin mode

== UI defaults
- ? preserve IME input mode state across sessions: http://code.google.com/p/ibus/issues/detail?id=1662
- current keyboard source should not determine layout when switching into an IME
- if there is ambiguity IME label could show the configured layout: eg "kkc (JP)" vs "kkc (US)"
- gnome-shell
- need discussion with Gnome people about the design and UI experience
- indicator should expand IME mode submenu by default, and be placed above IME list
- gnome-shell grabs Super-Space: https://bugzilla.gnome.org/show_bug.cgi?id=703779
- only show switcher when more than two input sources

We discussed some of this last week:

http://meetbot.fedoraproject.org/fedora-meeting/2014-02-05/i18n.2014-02-05-06.01.log.html#l-82

  • more metadata is needed on xkb maps
  • typing-booster could benefit from layout (keymap) switching rather than relying on libtranslit
  • perhaps it could be handled by IME
  • (Latin phonetic vs non-phonetic IME (input modes))
  • eg zh IMEs (other than pinyin) often assume/specify US layout
  • further cleanup/filtering of xkb maps
  • system config of keyboard geometry, which could restrict list of available keymaps/layouts
  • detection of keyboard type by USB?
  • classification of IMEs, keymaps/layouts and keyboard geometries
  • IMEs
    • Latin phonetic or not
    • should only list/use appropriate layouts
  • xkb
    • filter layouts by sufficient geometry
    • keyboard geometry should restrict available layouts
    • langtable already provides data on layouts with Latin support
  • more consistent handling for switching between xkb and IME Input Sources

  • gnome-shell issues

  • indicator should expand IME mode submenu by default, and be placed above IME list
  • gnome-shell grabs Super-Space: https://bugzilla.redhat.com/show_bug.cgi?id=844555
  • respect IME candidate list orientation config https://bugzilla.gnome.org/show_bug.cgi?id=719749

Replying to [comment:14 petersen]:

  • indicator should expand IME mode submenu by default, and

and be placed above IME list

I filed https://bugzilla.gnome.org/show_bug.cgi?id=725708 for this part
(and also mentioned about expanding the Input Mode submenu by default
but that might require ibus changes too?).

In [http://meetbot.fedoraproject.org/fedora-meeting/2014-03-05/i18n.2014-03-05-06.02.log.html#l-40 2014-03-05] i18n meeting we agreed to close this issue deferred
(so we can re-visit the xkb layout classification later),
after I file bugs in Fedora against IMEs to improve their input mode menus.
Need to do some testing first in Rawhide to check on status quo.

Discussed again in 2014-06-25 meeting.

Jens will do some testing in F21 Rawhide
while talking to IME maintainers and open bugs.

Maybe also compare the gnome and non-gnome IMEs menus.

2014-07-02 meeting

  • Jens will open an upstream bug for allowing input modes to appear in toplevel menu rather than submenu.
  • Mike will change ibus-table 5 state toggle to menu
  • Jens filed https://bugzilla.redhat.com/show_bug.cgi?id=1115295 to improve Pinyin toggle menu UI if possible
  • Fujiwara pointed out http://fujiwara.fedorapeople.org/ibus/win8menu/ screenshots
  • Fujiwara will discuss again with upstream about having input mode icon in non-gnome like for gnome but will be for post-F21.
  • also upstream ibus-setup patch to drop "Customize IMEs" toggle will hopefully be ready for f21.

Closing this out since the major topics have been covered and cleared.
More work will proceed and come from this discussion.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1116676 for the xkb geometry/layout "R&D" analysis RFE.

Login to comment on this ticket.

Metadata