Qtcreator placed in docker container on Ubuntu 18.04 cannot input Japanese using ibus

Host OS: ubuntu-desktop 18.04
docker image: Installation of development tools and libraries you want to use for ubuntu-desktop 18.04

In this configuration, I cannot input Japanese in the qtcreator running in the docker container.
Specifically, the input indicator does not change from "A" to "A" when you press full/half-width.
It can be done with qtcreator on the host OS side.The qtcreator is part of the ubuntu distribution.

I think ubuntu is the default, but I use ibus-mozc.

The environment variables you think are related to are as follows:

QT_IM_MODULE=ibus
LANG=ja_JP.UTF-8

Some of the packages installed in the docker container that you think are directly related to are:

qtcreator
ibus
ibus-mozc

When starting the container, I am mounting /tmp/.XIM-unix, although I do not understand if it is meaningful.

I don't know how ibus communicates (I looked it up in my own way), so
There are no sockets or ports connected to enable ibus communication.

In this state, you may or may not be able to:

You can enter Japanese using ibus on xfce4-terminal launched in a container
You can enter Japanese using ibus with emacs25 launched in the container
Enable Japanese input on the exclusive 2019-12 CDT launched in the container
Cannot enter Japanese with qtcreator launched in container

Are you missing/misunderstanding anything?

After posting, I found out the basics.

ibus uses "dbus" for communication.ibus is a dbus application.
dbus uses unix domain socket for communication.It also uses abstract path, which is invisible to ordinary file systems.
The abstract path is independent for each network name space, so when using docker container normally, it is separated from the host in the container, so it is not visible. https://stackoverflow.com/questions/38455283/docker-containers-share-unix-abstract-socket-or-dbus

If so, I think that the ibus that appeared to be available in the container was not able to communicate with ibus.The ibus server seems to also serve as an "xim" server, so I guess it's communicating as "xim".

docker qt

2022-09-30 14:56

1 Answers

Answer yourself

Using the ibus daemon running on the host, I found it difficult to input Japanese on the desktop application running in the docker container.The reason is that ibus uses a protocol that uses dbus.

Instead, the conversion using fcitx worked, so I will introduce it to you.
The fcitx seems to be using a regular unix domain socket (socket with a path that exists on the file system), so you can communicate as long as you mount it in the docker container.

installing fcitx

On the host OS side, it was installed on my own. Both fcitx and ibus are installed, so I need to configure fcitx to be used (to launch the fcitx daemon).

Under Settings | Language and Support, select fcitx from the IM System used for keyboard input pull-down.

Install the fcitx binary in the Docker image.The conversion daemon is from the host OS, so you only need to include the front-end package.Among Dockerfile, I am

 apt-get install-y fcitx-frontend-all

specified.

Specify in docker run

Mounts /tmp/fcitx-socket-:0 which is the unix domain socket for which fcitx accepts requests when docker container is started. The --volume option in docker run does not handle cases with colons in the pathname, so use the --mount option (https://stackoverflow.com/questions/44938108/unable-to-map-docker-volume-with-colon)
The host also takes over the environment variables to ensure fcitx is used.

docker run...omitted...\
   --env="QT_IM_MODULE"\
   --env="QT4_IM_MODULE"\
   --mount type=bind, source=/tmp/fcitx-socket-:0, destination=/tmp/fcitx-socket-:0\
   ...abbreviated later

Now you can type in Japanese in the qtcreator in the container.

2022-09-30 14:56

If you have any answers or tips

Popular Tags

python x 4647

android x 1593

java x 1494

javascript x 1427

c x 927

c++ x 878

ruby-on-rails x 696

php x 692

python3 x 685

html x 656