I would like ibus not to be auto-started. However, I failed to figure out how to disable it. Could you please share some general methods on how to debug this?
(Put them under git version control to see new files after package
installation.)
Or check apt-file list pkg-name for newly installed packages.
Since there are a lot of configuration and packages need to be installed. Should I create two new packages? e.g. localization-gateway and localization-gateway and then set those two packages depend on IM and fronts packages?
Also the technical background of Debian Packages - Whonix is very messy. Meaning no one would be able to ever remove these language packages without being affected by that mess.
Could you make it a weak dependency please? (the forum search explains this term a bit) Basically:
It’s necessary for Qubes-Whonix, too. For example, after installing these packages, the KDE user interface invoked by kdesudo whonix-setup-wizard locale_settings can be shown in a different language, allowing user to do further localization settings.
The proper way to configure input method is using im-config. This is how it works from man im-config:
The im-config package installs a hook script /etc/X11/Xsession.d/70im-config_launch. When X starts, it sources this file as a POSIX shell code. Then this hook script tries to source the user configuration file ~/.xinputrc, if it exists.
My understanding is:
Input method (ibus) should only be install in Whonix-Workstation, not Whonox-Gateway as it is not the place to work.
For Qubes-Whonix, We don’t want the ibus icon to be shown for every VM started. Because it is not only against Qubes policy, but also makes the interface messy by having a bunch of similar looking icons.
For non-Qubes-Whonix, it is okay to start ibus by default as a single icon does not hurt anybody and allows easier input method configuration.
By default, ibus will be used by im-config. Therefore:
in Qubes-Whonix case, we need to execute im-config -n none after the installation of ibus and im-config. And let user who needs ibus use im-config -n ibus.
in non-Qubes-Whonix, we need to do nothing.
Alternatively, a platform interdependent solution is only invoking ibus when the $LANG is set to a different and available language. /usr/share/im-config/data/02_cjkv.rc is shipped with im-config for this purpose. We simply change ~/.xinputrc to:
user@language:~$ cat ~/.xinputrc
# start most popular available input method automatically
# for Chinese, Japanese, Korean, Vietnamese
case $LANG in
zh_*.*|ja_JP.*|ko_KR.*|vi_VN.*)
run_im ibus
;;
*)
run_im none
;;
esac
It seems this doesn’t work with a TemplateBasedVM which is based on a TemplateVM with $LANG set to English. Even if we write export LANG='zh_CN.utf8' to ~/.bashrc, at the time ~/.xinputrc is executed, $LANG is still English.
I see. Since we are a distribution please drop eventual required snippets into /etc/X11/Xsession.d and don’t write into the home folder. For your kind consideration:
Let’s not install it on Whonix-Gateway for now and listen to user feedback.
Correct.
It’s not great but acceptable. A first time wizard would be better to avoid this systray icon for those not needing it?
Seems better. Ought to avoid ~/.xinputrc home folder with more appropriate folder though.
Is xinputrc processed at all in Qubes?
A web search for "qubes" ".xinputrc" shows some results.
Maybe Redirecting to Google Groups - didn’t throughly read.
Then this hook script tries to source the user configuration
file ~/.xinputrc, if it exists. Otherwise, this hook script sources
the system configuration file /etc/X11/xinit/xinputrc.
I believe it is executed because when this will make ibus invoked:
user@chinese:~$ cat .xinputrc
# start most popular available input method automatically
# for Chinese, Japanese, Korean, Vietnamese
case $LANG in
zh_*.*|ja_JP.*|ko_KR.*|vi_VN.*)
run_im ibus
;;
*)
run_im ibus # here is the only difference
;;
esac
user@chinese:~$ cat /etc/X11/Xsession.d/60im-qubes-workaround
. /usr/local/etc/im-workaround ## couldn't be hackier but work
#. /home/user/.bashrc ## doesn't work
#export LANG='zh_CN.utf8' ## needs to modify TemplateVM
Then we need to create a tool in template based VM, that writes to /usr/local/etc/im-workaround:
I’ve thought about this idea. My conclusion is this is not a good idea in many aspects. The most important point is:
While it is safe to assume users who set $LANG to CJKV(Chinese/Japanese/Korean/Vietnam) will want ibus to be auto-started, not all the users who wants ibus to be auto-started would like to set $LANG to CJKV.
And even if we decide to implement it, a more standard way should be looking into these two files: /etc/X11/xinit/xinputrc and /etc/default/im-config
A simple, elegant and generic solution I found is as follows:
For developers, we need to replace /etc/X11/xinit/xinputrc file with a single line:
For users who needs to use ibus in VM (regardless of Qubes/non-Qubes/Standalone/TemplateBased):
type im-config -n ibus or use the Input Method option in Qubes Menu and select ibus.
restart the VM.
ibus will be ready to use upon the restart. Note that this needs to be done only once for a VM. ibus will be auto-started at every boot.
If they do not need to use ibus in the VM anymore:
type im-config -n none or use the Input Method option in Qubes Menu and select none.
kill ibus or restart the VM.
Pros:
a locales independent solution
a platform independent solution
seems that there’s no need to write anything to ~/.bashrc
very little work for users and the GUI solution is available
very little development and maintenance work for developer
Note:
Restarting the VM is required. If we manually run ibus-setup without rebooting, although the ibus daemon is started, we still can’t type non-English character.
If this solution looks good, here is the TODOs:
Figure out how to replace/etc/X11/xinit/xinputrc file.
Since the solution is generic enough, maybe talk to Qubes developers, too.
Document how to use input methods on Whonix Wiki and maybe Qubes Docs.
Right. Can’t $LANG being set to CJKV a triggering condition? Meaning, ibus can still be started on demand even if $LANG is set to something else?
Using some .d file would be much better. Replacing files owned by other packages always a unclean solution. Could you please explore if /etc/X11/Xsession.d/ works somehow and if not request a feature from upstream to provide a .d folder?
