12 ms·

Does Wayland have an input method story? Last I heard, GNOME was telling users that ibus was the only supported input method for their software; ibus doesn't ha

by gue5t 12y ago

Does Wayland have an input method story? Last I heard, GNOME was telling users that ibus was the only supported input method for their software; ibus doesn't have the same feature set or flexibility as my current setup, which involves switching between fcitx and XIM dynamically. Plus, what about being able to accessibly enter text into things other than ibus-bound GNOME applications? I've heard talk of a Wayland port of fcitx, but I could never get it to do anything at all, and it sounds like GNOME might not support it even if it does work? I'd love to hear how this all is supposed to work from someone who knows what's going on.

hyperion2010 12y ago
Apparently libinput is what is going to handle Wayland input and the X team is already moving to add it as an input option to x11 to ease the transition.
- gue5t 12y ago
  Libinput is a low-level library that handles and normalizes evdev (kernel) events. "Input methods" here refers to high-level ways of interpreting various devices' events to produce text input for programs that accept text: on-screen keyboards, predictive input, pinyin, and so on.
  - exDM69 12y ago
    Also plain old keyboard input is an important part of this. Dealing with international keyboard layouts is anything but trivial. E.g. to write ñ on my keyboard layout (fi), I need to press AltGr+~ and then n. In X11, this is handled by the XIM library. There's no shortage of applications that do this incorrectly. Particularly annoying are some games which don't get this right. The key for ", ^ and ~ is a "dead" key (doesn't produce any character output, to write ~ you press AltGr+~ and then space) which is where the US keyboard has ]. Lots of games use [] for something important, and this completely fails to work on my key layout. For game keyboard input, the game should use "raw" scan codes (which are keyboard specific) for all configurable keys. Ie. not "keysyms" and especially not character codes. International keyboard handling is very difficult. I was talking about a mostly western key layout, I don't even want to know what it's like to deal with non-western keyboard layouts (russian, greek, chinese, japanese, etc).
    - pjmlp 12y ago
      One of my pains on the early GNU/Linux days (slackware 2.0 and beyond) was to configure the keyboard for Portuguese both on the console and on X. Almost as fun as finding out the right modes not to burn the monitor.
    - ygra 12y ago
      > International keyboard handling is very difficult. I was talking about a mostly western key layout, I don't even want to know what it's like to deal with non-western keyboard layouts (russian, greek, chinese, japanese, etc). The difficulty here is getting things like dead keys, key combinations (AltGr) and Compose right. Everything after that simply generates a Unicode string in the application. At which point the script is irrelevant. In fact, the difficult parts here happen completely below anything that needs text, so language or script is a non-issue at that point.
  - chongli 12y ago
    Why not have said "high level" methods available at a low level? What if I want to write Chinese in my config files while editing with vi on a tty running through the system fb console?
- sandGorgon 12y ago
  does anyone know if it will solve the consistent copy-paste shortcut problem in Linux. Yes, I know we cant use ctrl-c .... but the lack of consistency which I see on OSX is frustrating.
runiq 12y ago
I'm curious: Why do you switch between fcitx and XIM? What are the advantages of one over the other, and in what situations?
- gue5t 12y ago
  Most input methods, including fcitx, don't follow the user-specified compose-key sequences in ~/.XCompose, but XIM specifically does. In the other direction, fcitx supports C-S-u NNN to enter characters by codepoint value but XIM doesn't. For the trifecta of compose-key, pinyin, and one-off symbols I haven't found anything better than switching off.

by gue5t 12y ago

hyperion2010 12y ago

Apparently libinput is what is going to handle Wayland input and the X team is already moving to add it as an input option to x11 to ease the transition.

gue5t 12y ago
Libinput is a low-level library that handles and normalizes evdev (kernel) events. "Input methods" here refers to high-level ways of interpreting various devices' events to produce text input for programs that accept text: on-screen keyboards, predictive input, pinyin, and so on.
- exDM69 12y ago
  Also plain old keyboard input is an important part of this. Dealing with international keyboard layouts is anything but trivial. E.g. to write ñ on my keyboard layout (fi), I need to press AltGr+~ and then n. In X11, this is handled by the XIM library. There's no shortage of applications that do this incorrectly. Particularly annoying are some games which don't get this right. The key for ", ^ and ~ is a "dead" key (doesn't produce any character output, to write ~ you press AltGr+~ and then space) which is where the US keyboard has ]. Lots of games use [] for something important, and this completely fails to work on my key layout. For game keyboard input, the game should use "raw" scan codes (which are keyboard specific) for all configurable keys. Ie. not "keysyms" and especially not character codes. International keyboard handling is very difficult. I was talking about a mostly western key layout, I don't even want to know what it's like to deal with non-western keyboard layouts (russian, greek, chinese, japanese, etc).
  - pjmlp 12y ago
    One of my pains on the early GNU/Linux days (slackware 2.0 and beyond) was to configure the keyboard for Portuguese both on the console and on X. Almost as fun as finding out the right modes not to burn the monitor.
  - ygra 12y ago
    > International keyboard handling is very difficult. I was talking about a mostly western key layout, I don't even want to know what it's like to deal with non-western keyboard layouts (russian, greek, chinese, japanese, etc). The difficulty here is getting things like dead keys, key combinations (AltGr) and Compose right. Everything after that simply generates a Unicode string in the application. At which point the script is irrelevant. In fact, the difficult parts here happen completely below anything that needs text, so language or script is a non-issue at that point.
- chongli 12y ago
  Why not have said "high level" methods available at a low level? What if I want to write Chinese in my config files while editing with vi on a tty running through the system fb console?
sandGorgon 12y ago
does anyone know if it will solve the consistent copy-paste shortcut problem in Linux. Yes, I know we cant use ctrl-c .... but the lack of consistency which I see on OSX is frustrating.

runiq 12y ago

I'm curious: Why do you switch between fcitx and XIM? What are the advantages of one over the other, and in what situations?

gue5t 12y ago
Most input methods, including fcitx, don't follow the user-specified compose-key sequences in ~/.XCompose, but XIM specifically does. In the other direction, fcitx supports C-S-u NNN to enter characters by codepoint value but XIM doesn't. For the trifecta of compose-key, pinyin, and one-off symbols I haven't found anything better than switching off.