Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm running Kubuntu with KDE as my main desktop environment.

A while ago I set up dead keys so I can type Chinese pinyin and other accented letters and special characters.

As a side note, I use IBUS because it seemed to be easiest to set up my Chinese character IMEs with.

Until the update, dead/compose keys worked fine in all applications.

Now, they work in QT applications, but not GTK ones (such as this browser). This is unfortunate, as it's where I do most of my typing. My workaround right now is to type accents into KDE's launcher and copy past (Alt+F2, type using dead keys, Ctrl+X, Esc, Ctrl+V), which is kind of a hassle.

I'm not sure what information is useful in debugging this, as it's been a while since I set this all up.

Interestingly, the environment variable $QT_IM_MODULE has no value. $GTK_IM_MODULE has xim.

I have ibus-gtk3 installed, I can post whatever information else would be helpful in diagnosing.

I have pasted below the setup script that is in various places (ex. en_US, /etc/X11/xinit/xinput.d/ibus, etc.). I'm not sure which one takes priority, and I'm not sure any are being run, as QT_IM_MODULE has no value when I echo it, whereas these all indicate it should be "xim" by default if not ibus.

I should mention also that the libraries (im-ibus.so, etc) mentioned below I do not have, nor can I find how to get them or where they are to link them. In fact, my gtk-3.0.0/ and qt4/ directories do not even have an inputmethod/ or plugin/ directory. This may be part of the problem, but again, it was working before the update, so I don't know.

# start IBus
# vim: set sts=4 expandtab:

# start IBus daemon
#/usr/bin/ibus-daemon --daemonize --xim
XIM=ibus
XIM_PROGRAM=/usr/bin/ibus-daemon
XIM_ARGS="--xim"

# set variables for the plain XIM
XMODIFIERS=@im=ibus

GTK_IM_MODULE=xim
# use immodule only when available for both GTK 2.0 and 3.0
IM_CONFIG_MARKER2=0
for IM_CONFIG_MARKER in /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
                        /usr/lib/gtk-2.0/*/immodules/im-ibus.so ; do
    if [ -e $IM_CONFIG_MARKER ]; then
        IM_CONFIG_MARKER2=1
        break
    fi
done

IM_CONFIG_MARKER3=0
for IM_CONFIG_MARKER in /usr/lib/*/gtk-3.0/*/immodules/im-ibus.so \
                        /usr/lib/gtk-3.0/*/immodules/im-ibus.so ; do
    if [ -e $IM_CONFIG_MARKER ]; then
        IM_CONFIG_MARKER3=1
        break
    fi
done
if [ $IM_CONFIG_MARKER2 = 1 ] && [ $IM_CONFIG_MARKER3 = 1 ] ; then
    GTK_IM_MODULE=ibus
fi

QT_IM_MODULE=xim
# use immodule when available for Qt4 (Qt3 has been long dead)
for IM_CONFIG_MARKER in /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so\
                        /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so ; do
    if [ -e $IM_CONFIG_MARKER ]; then
        QT_IM_MODULE=ibus
        break
    fi
done

CLUTTER_IM_MODULE=xim
# use immodule when available for clutter
for IM_CONFIG_MARKER in /usr/lib/*/clutter-imcontext/immodules/im-ibus.so \
                        /usr/lib/clutter-imcontext/immodules/im-ibus.so; do
    if [ -e $IM_CONFIG_MARKER ]; then
        CLUTTER_IM_MODULE=ibus
        break
    fi
done

DEPENDS="ibus, ibus-gtk|ibus-qt4|ibus-clutter"
share|improve this question

3 Answers 3

This may be related - or not. Since several months, the compose key stops working, after a while. I defined an .Xmodmap which defines the keys, and after running xmodmap it works, at least to finish a document or so. But after a couple of hours (?) it just disappears.

No log-out, no opening apps. I have not been able to pinpoint any event which could cause this. Just maybe, it might be keyboard-action related. I switched keyboards and it seems to happen less than before.

share|improve this answer

If you use an input module at the X11 level (eg, one defined by XMODIFIERS=…), then X11 doesn't handle dead keys nor compose anymore, it is up to the input module to do it.

What you would need would be a way to switch between XMODIFIERS="@im=ibus" and XMODIFIERS="@im=none" (to let X11 do the work). Maybe there is already a Gtk configuration to do that and have it appear on the right-click menu of input methods; if not, it would be a nice suggestion to Gtk/Gnome team :)

share|improve this answer
1  
XMODIFIERS="@im=none" partially resolved also my problem with the Compose key unix.stackexchange.com/q/60884/1662 Selecting None from the Input method context menu did't help. Qt apps still don't handle the Compose key right. Thanks. But where are all these changes documented? –  sastanin May 29 '13 at 8:07
    
"Where is this documented" is the most important question indeed (it seems like the answer is: nowhere). :( –  JanC Feb 8 at 17:09
    
Well, I know that because I worked on the input support in the "old days"; probably there is no documentation (or hard to find). The thing is that the special input methods (those using XMODIFIERS) use the same mechanism (or based on the same mechanism) as the "default" (eg: @im=non, which can be omitted); so it is one or the other, if you use a specific input method, then the default X11 one is not called. –  Pablo Saratxaga Feb 9 at 11:40
    
On the other hand, modern toolkits (Qt, Gtk,...) skeep completly the X11 input layer (they use their own stuff on top of the raw X11 input). However, they also provide a way to still use the X11 input (eg: XMODIFIERS). The thing is that "none" in the context of a Gtk/Qt/... program means the default input method of the Gtk/Qt/... toolkit; while the XMODIFIERS="@im=non" (eg let X11 handle dead keys) is an "X11 input method", so the results may differ. –  Pablo Saratxaga Feb 9 at 11:46

X input model is very complex (some even say that only 5 people on earth fully understand it :) I'm not one of them btw)

a) So, at the beginning, you had just an X11 function that read the keyboard, one key one symbol.

b) But some people wanted dead keys, so another function allows for, it, several keys, one string. This also need one or several files to describe which sequences of keys produce which sequences of characters.

c) Then there are also more complex input methods, that interact with another, server-like, program. That is typically done to type in japanese or chinese.

For b) and c) to work you need an XMODIFIERS varaible correctly defined "@im=none" for b) (for c) the value of @im=xxxxx depends of the 3d program used); and proper configuration of everything, and that the application uses the right input functions (some X11 programs are still around that only use the raw function in a), no luck then :( )

d) Then, as all that was too complex, and particularly c) had a very ugly interaction; modern toolkits like Qt and Gtk, started to provide their own input level suport, bypassing b)/c)

So you have the choices to use the input method of the toolkit (but then it will differ between Gtk/Qt/other ); or use b)/c) (b or c depends mainly of the language you want to type). But to use b/c, you have to tell your high level toolkit not to do it itself, but to let X11 do it. In Gtk there is an input called "XIM server input" or something like that; when choosing it you use the b/c method.

Qt should have a similar thing. With KDE3 (Qt3) having a shell variable QT_IM_MODULE=xim was enough. Now, it's possible that a dynamic (eg trough the GUI and dbus) configuration has priority over the shell variable.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.