업그레이드 후 GTK 애플리케이션에서 작동하지 않는(작성) 키가 작동하지 않음

업그레이드 후 GTK 애플리케이션에서 작동하지 않는(작성) 키가 작동하지 않음

저는 Kubuntu를 실행하고 KDE를 기본 데스크탑 환경으로 사용하고 있습니다.

얼마 전에는 중국어 병음과 기타 악센트 문자 및 특수 문자를 입력할 수 있도록 데드 키를 설정했습니다.

그런데 저는 한자 입력 방법을 설정하는 가장 쉬운 방법인 것 같아서 IBUS를 사용하고 있습니다.

업데이트 전에는 모든 앱에서 데드 키/키 조합이 제대로 작동했습니다.

이제 QT 애플리케이션에서는 작동하지만 GTK 애플리케이션(예: 이 브라우저)에서는 작동하지 않습니다. 제가 타이핑을 가장 많이 하는 곳이기 때문에 불행한 일입니다. 현재 해결책은 KDE 실행 프로그램에 악센트 문자를 입력하고 복사하는 것입니다(Alt+F2, 데드 키를 사용하여 입력, Ctrl+X, Esc, Ctrl+V). 이는 약간 번거롭습니다.

이 모든 것을 설정한 지 꽤 오래되었기 때문에 어떤 정보가 디버깅에 유용할지 잘 모르겠습니다.

흥미롭게도 환경 변수 $QT_IM_MODULE에는 값이 없습니다. $GTK_IM_MODULE에는 xim이 있습니다.

ibus-gtk3을 설치했습니다. 진단에 도움이 될 수 있는 다른 정보를 게시할 수 있나요?

설치 스크립트를 다양한 위치(예: en_US, /etc/X11/xinit/xinput.d/ibus 등)에 붙여넣었습니다. 어느 것이 우선하는지 잘 모르겠고, 에코할 때 QT_IM_MODULE에 값이 없기 때문에 둘 중 하나가 실행 중인지 확실하지 않습니다. 둘 다 ibus가 아닌 경우 기본적으로 "xim"이어야 한다고 제안합니다.

또한 아래에 언급된 라이브러리(im-ibus.so 등)가 없으며 해당 라이브러리를 얻는 방법이나 라이브러리에 대한 링크를 찾을 수 없다는 점도 언급해야 합니다. 사실 내 gtk-3.0.0/ 및 qt4/ 디렉토리에는 inputmethod/ 또는 플러그인/ 디렉토리도 없습니다. 그게 문제의 일부일 수도 있지만, 업데이트 전에도 작동했으므로 잘 모르겠습니다.

# 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"

답변1

X11 수준에서 입력 모듈을 사용하는 경우(예: 정의된 입력 모듈에 의해 XMODIFIERS=…) X11은 더 이상 데드 키나 조합을 처리하지 않지만 입력 모듈은 이를 수행합니다.

당신에게 필요한 것은 XMODIFIERS="@im=ibus"와 사이를 전환하는 방법 입니다 XMODIFIERS="@im=none"(X11이 작업을 하도록 하십시오). 아마도 이 작업을 수행하기 위한 Gtk 구성이 이미 있고 입력 방법의 오른쪽 클릭 메뉴에 표시되도록 할 수도 있습니다. 그렇지 않은 경우 이는 Gtk/Gnome 팀에게 좋은 제안입니다.

답변2

X 입력 모델은 매우 복잡합니다. (어떤 사람은 이 모델을 완전히 이해하는 사람이 지구상에 5명밖에 없다고 말하기도 했습니다. 저는 그중 하나가 아닙니다.)

a) 따라서 처음에는 기호당 하나의 키로 키보드를 읽는 X11 기능만 있습니다.

b) 하지만 어떤 사람들은 데드 키를 원하기 때문에 또 다른 함수에서는 여러 키, 즉 문자열을 허용합니다. 또한 어떤 키 시퀀스가 ​​어떤 문자 시퀀스를 생성하는지 설명하는 하나 이상의 파일이 필요합니다.

c) 다른 서버형 프로그램과 상호 작용하는 더 복잡한 입력 방법도 있습니다. 이는 일반적으로 일본어 또는 중국어를 입력하는 데 사용됩니다.

b)와 c)가 작동하려면 b)에 대해 XMODIFIERS 변수 "@im=none"을 올바르게 정의해야 합니다(c의 경우 @im=xxxxx 값은 사용된 3D 프로그램에 따라 다름).그리고모든 것이 올바르게 구성되었습니다.그리고올바른 입력 기능(일부 X11 프로그램이 여전히 존재하며 a의 원래 기능만 사용함)을 사용하는 애플리케이션은 운이 좋지 않습니다.

d) 그런 다음 이 모든 것이 너무 복잡하고 특히 c)의 상호 작용이 매우 보기 흉하기 때문에 Qt 및 Gtk와 같은 최신 툴킷은 b)/c)를 우회하여 자체 입력 수준 지원을 제공하기 시작했습니다.

따라서 툴킷의 입력 방법을 사용하도록 선택할 수 있습니다(그러나 Gtk/Qt/기타 간에는 다릅니다). 또는 b)/c)를 사용할 수 있습니다(b 또는 c는 주로 입력하려는 언어에 따라 다릅니다). 하지만 이를 b/c로 사용하려면 고급 툴킷에 직접 수행하지 말고 X11에서 수행하도록 해야 합니다. Gtk에는 "XIM 서버 입력"이라는 입력이 있습니다. b/c를 선택할 때 해당 방법을 사용합니다.

Qt에도 비슷한 것이 있어야 합니다. KDE3(Qt3)의 경우 쉘 변수로 QT_IM_MODULE=xim충분합니다. 이제 동적(예: GUI 및 dbus를 통한) 구성이 쉘 변수보다 우선할 수 있습니다.

답변3

이는 관련이 있을 수도 있고 그렇지 않을 수도 있습니다. 몇 달 동안 작성 키가 잠시 후 작동을 멈췄습니다. 키를 정의하기 위해 .Xmodmap을 정의했고, xmodmap을 실행한 후 적어도 하나의 문서에 대해서는 작동했습니다. 그런데 몇 시간(?) 지나자 사라졌습니다.

로그아웃할 필요도 없고, 앱을 열 필요도 없습니다. 이 문제를 일으킬 수 있는 이벤트를 정확히 찾아낼 수 없습니다. 어쩌면 키보드 조작과 관련이 있을 수도 있습니다. 키보드를 바꾸었는데 이전보다 이런 일이 덜 일어나는 것 같습니다.

관련 정보