Bug 1568365

I cannot reproduce your problem.
Which locale do you use?
If you use non-CJK, ibus-daemon is not running by default and you need to use im-chooser.

(In reply to Bernie Innocenti from comment #0)
> On the same system, ibus-daemon starts normally from the Gnome Shell session.

Yes, GNOME has a different logic and ibus-daemon always runs whether you use or not.

well, that may depends on how you installed KDE Plasma on your box. if it was from Live, I'm afraid that is NOTABUG because of https://pagure.io/fedora-kickstarts/blob/master/f/fedora-kde-minimization.ks#_3

try dnf groupinstall input-methods

and/or ask for getting rid of that line from .ks there.

My locale is en_US.UTF-8 and I'm using ibus + mozc for Japanese input.

Indeed, running im-chooser and selecting ibus fixed the issue for me: it created a symlink from ~/.config/imsettings/xinputrc to /etc/X11/xinit/xinput.d/ibus.conf, which causes ibus-daemon to start as expected at login time.

I didn't have to install any new packages (dnf groupinstall input-methods brings in a huge number of dependencies!).

Would it be a good idea to open a separate bug for improving the overall user experience of configuring input methods? Every time I switch distro, desktop, or machine, I end up spending a *huge* amount of time figuring out how to get Japanese input to work. The main issues I encountered are:

1. there are *way* too many combinations of toolkit's IM module + IM framework + language-specific IM + desktop applet + configuration GUI

2. documentation is scattered around the Internet, it's often distro-specific or desktop-specific, and too often recommends components that are no longer being maintained

3. hard to find upstream projects with so many forks and abandoned repositories. Just deleting dead projects would save users a lot of dead ends

4. Specific to Japanese: defaults assume a Japanese keyboard with mode switching keys. There should be an obvious way to setup things for US keyboards using the same shortcuts of Windows or OS X

Happy to move this topic to a different bugzilla component or on a mailing-list, but which one?

(In reply to Bernie Innocenti from comment #3)
> Would it be a good idea to open a separate bug for improving the overall
> user experience of configuring input methods? Every time I switch distro,
> desktop, or machine, I end up spending a *huge* amount of time figuring out
> how to get Japanese input to work. The main issues I encountered are:

I don't think there is any bugs or improvements.
EN locale has stopped to run input methods before Fedora 27 but GNOME changed the legacy process.

You could see _im_language_list in /etc/X11/xinit/xinitrc.d/50-xinput.sh .

> 1. there are *way* too many combinations of toolkit's IM module + IM framework + language-specific IM + desktop applet + configuration GUI

And what is your problem?

> 2. documentation is scattered around the Internet, it's often
> distro-specific or desktop-specific, and too often recommends components
> that are no longer being maintained

Probably we can document https://fedoraproject.org/wiki/I18N/InputMethods for that basic topic.

> 3. hard to find upstream projects with so many forks and abandoned
> repositories. Just deleting dead projects would save users a lot of dead ends

Probably you can check URL in spec files for the rpm builds.

> 4. Specific to Japanese: defaults assume a Japanese keyboard with mode
> switching keys. There should be an obvious way to setup things for US
> keyboards using the same shortcuts of Windows or OS X

I don't understand what you mean here.
Can you elaborate it?

> Happy to move this topic to a different bugzilla component or on a
> mailing-list, but which one?

Talking in this bugzilla is no problem with me but I think a new bugzilla is not good for this.
i18n.org or #fedora-g11n @ Freenode or #ibus @ Freenode would be an option.

(In reply to fujiwara from comment #4)
> (In reply to Bernie Innocenti from comment #3)
> > Would it be a good idea to open a separate bug for improving the overall
> > user experience of configuring input methods? Every time I switch distro,
> > desktop, or machine, I end up spending a *huge* amount of time figuring out
> > how to get Japanese input to work. The main issues I encountered are:
> 
> I don't think there is any bugs or improvements.
> EN locale has stopped to run input methods before Fedora 27 but GNOME
> changed the legacy process.
> 
> You could see _im_language_list in /etc/X11/xinit/xinitrc.d/50-xinput.sh .

Right above the list, it says:

    # FIXME: This hardcoded list has to be gone in the future.
    # Locales that normally use input-method for native input

What's the harm in starting ibus unconditionally? If I understand the script correctly, that's just falling back to xim for some other locales.

Is it correct to assume that xim is going away due to Wayland, and the languages still using it will have to migrate to ibus?


> > 1. there are *way* too many combinations of toolkit's IM module + IM framework + language-specific IM + desktop applet + configuration GUI
> 
> And what is your problem?

New users often need to tinker until they find a combination that works. On other systems, users don't need to become experts in the input stack just to add an IM.


> > 2. documentation is scattered around the Internet, it's often
> > distro-specific or desktop-specific, and too often recommends components
> > that are no longer being maintained
> 
> Probably we can document https://fedoraproject.org/wiki/I18N/InputMethods
> for that basic topic.

Would be good if that page could be updated to move the non-default IMs near the bottom (and just remove any mention of those which are not production quality in F27 / F28 (either because they're bitrotting or because they're not ready yet).

Perhaps better from the perspective of end-users: the page could be re-organized by language, to help answer the basic question "How do I configure Fedora for typing in $LANG?"


> > 3. hard to find upstream projects with so many forks and abandoned
> > repositories. Just deleting dead projects would save users a lot of dead ends
> 
> Probably you can check URL in spec files for the rpm builds.
> 
> > 4. Specific to Japanese: defaults assume a Japanese keyboard with mode
> > switching keys. There should be an obvious way to setup things for US
> > keyboards using the same shortcuts of Windows or OS X
> 
> I don't understand what you mean here.
> Can you elaborate it?

US keyboards lack the dedicated language input keys. Both Windows and MacOS defined shortcuts to switch modes using keys present on all keyboards:

  https://en.wikipedia.org/wiki/Language_input_keys#Keys_for_Japanese_Keyboards

In Linux (at least in mozc) these shortcuts are not present in the default configuration. Users must navigate the configuration options and edit 6-7 different shortcuts manually. I have to re-discover how to do this every time I get a new Linux machine, and it's very annoying.


> > Happy to move this topic to a different bugzilla component or on a
> > mailing-list, but which one?
> 
> Talking in this bugzilla is no problem with me but I think a new bugzilla is
> not good for this.
> i18n.org or #fedora-g11n @ Freenode or #ibus @ Freenode
> would be an option.

I logged into #fedora-g11n and said hi.

Thank you for maintaining the IM stack, I hope all my criticism doesn't make it sound like I don't appreciate all the work that is being done :-)

> Right above the list, it says:
> 
>     # FIXME: This hardcoded list has to be gone in the future.

I don't know what kind of customization you want but you can put xinputrc in users home directories if you want to enable ibus before users log in.

>     # Locales that normally use input-method for native input

I don't understand this.

> What's the harm in starting ibus unconditionally? If I understand the script
> correctly, that's just falling back to xim for some other locales.

You could see /etc/X11/xinit/xinput.d/none.conf
Most EN users would not need ibus-daemon by default and I think we keep the compatibility.
If you need to enable it, you can run im-chooser.

The default XIM is for QT only. and GTK is gtk-im-context-simple which is same between non-GNOME and GNOME. The difference is that GNOME runs ibus-daemon for any locales but GNOME enables ibus for CJK only by default.
(Exactly it's not CJK only but I'd note it to simply the discussion.)

We cannot replace IBus with other input method frameworks easily in GNOME because GNOME has a hardcode to run ibus-daemon but you can select other IMFs with im-chooser in other desktops.

> Is it correct to assume that xim is going away due to Wayland, and the
> languages still using it will have to migrate to ibus?

I think there is a fallback.

> New users often need to tinker until they find a combination that works. On
> other systems, users don't need to become experts in the input stack just to
> add an IM.

You can use im-chooser without the knowledge.

> Perhaps better from the perspective of end-users: the page could be
> re-organized by language, to help answer the basic question "How do I
> configure Fedora for typing in $LANG?"

If I have time.

> US keyboards lack the dedicated language input keys. Both Windows and MacOS
> defined shortcuts to switch modes using keys present on all keyboards:
> 
>  
> https://en.wikipedia.org/wiki/Language_input_keys#Keys_for_Japanese_Keyboards
> 
> In Linux (at least in mozc) these shortcuts are not present in the default
> configuration. Users must navigate the configuration options and edit 6-7
> different shortcuts manually. I have to re-discover how to do this every
> time I get a new Linux machine, and it's very annoying.

Still not sure which shortcut keys you indicate.
IBus and MS-Windows uses Super-space key to switch IMEs and ibus-anthy defines several shortcut keys. I'm not sure about mozc.