色々とヒントをいただきありがとうございます。 バッファに溜まっていたキー入力が吐き出される時に、 imDefLkup.c,359: Tried to fabricate a wrong key event. や imDefLkup.c,419: The application disposed a key event with 695 serial. といったメッセージが、 mlterm を起動したターミナルに吐き出されているのに 気づきました。やはり青木さんのおっしゃるとおり XIM がらみの問題らしい ということで、mlterm を FCITX オプションつきで build し、 mlterm 設定ウインドウ(mlterm ウインドウ上で ctrl + mouse 3)から、input method を XIM -> FCITX に変更した所、おかしな挙動もぴたりと収まり、以 前と同様にマウスカーソルがタイトルバーやフレームにあってもキー入力がで きるようになりました。
XIMの問題の犯人はわからず終いですが、ここ数週間の私の問題は無事解決で きました。MLで相談してみて本当によかったです。 ありがとうございました。 松田 From: Tomoaki AOKI <junch...@dec.sakura.ne.jp> Subject: Re: mlterm のキー入力 Date: Mon, 31 Mar 2025 03:06:56 +0900 > 青木@名古屋です。 > > On Mon, 31 Mar 2025 01:28:03 +0900 (JST) > Osamu Matsuda <omats...@eng.hokudai.ac.jp> wrote: > >> 青木様 >> >> 情報ありがとうございます。 >> >> From: Tomoaki AOKI <junch...@dec.sakura.ne.jp> >> Subject: Re: mlterm のキー入力 >> Date: Sun, 30 Mar 2025 21:00:13 +0900 >> >> > On Sun, 30 Mar 2025 20:06:09 +0900 (JST) >> > Osamu Matsuda <omats...@eng.hokudai.ac.jp> wrote: >> > >> >> こんにちは。 >> >> >> >> 長い間 fvwm2 (今は fvwm3) で mlterm のお世話になっており、現在は >> >> fvwm3-1.1.0_6 と mlterm-3.9.3_2 を 14.2-RELEASE-p1 と xorg-7.7_3 で使っ >> >> ております。 >> >> >> >> 3月の始め頃に ports の更新を行ってから以下の状況になり困っております。 >> >> >> >> mlterm のウインドウを選んで raise するためにタイトルバーや枠をクリッ >> >> クするのですが(私は auto raise を使っておりません)、マウスカーソルが >> >> タイトルバーやフレームの上に乗っている状態だと、キー入力を受け付けて >> >> くれません。キー入力をするためにはマウスカーソルをウインドウの中 >> >> (mltermの画面と言えばよいのでしょうか)に入れる必要があります。 >> >> >> >> 以前はマウスカーソルがタイトルバーやフレームに乗っている状態でもキー入 >> >> 力ができました。些細なことですが、ウインドウを選んだ後、少しマウスカー >> >> ソルを動かす必要があるのが恐ろしくストレスになります。 >> >> >> >> 例えば xterm や emacs(X11上で動作しているもの)は、このようなことはなく、 >> >> マウスカーソルがタイトルバーやフレームに乗っている状態でも、問題なくキー >> >> 入力ができます。 >> >> >> >> なんとか以前の状態に戻したいのですが、何かご存知の方はいらっしゃいます >> >> でしょうか？ >> >> >> >> 松田 >> > >> > 青木@名古屋です。 >> > >> > 解決策ではなく「くさい部分」ですが、そのあたりに挙動に影響すると >> > すれば、FreshPorts [1] に現れるデフォルトでの直接依存分では >> > >> > x11-toolkits/vte3 [2] >> > >> > x11-toolkits/gtk30 [3] >> > >> > devel/glib20 [4] >> > >> > あとは少し可能性が下がって >> > >> > accessibility/at-spi2-core [5] >> > >> > あたりでしょうか。 他、各々の依存物ですが、通常真っ先に疑う >> > x11/libXiは最近更新されていませんしxtermやemacsが大丈夫と >> > なると違いそうです。 >> > >> > [1]を見るとinput methodとして（デフォルトでは全部Offですが） >> > FCITX，IBUS，M17NLIB，SCIM及びUIMが選択できるようになっている >> > ということはどれかを有効にするか（恐らくどれも有効になっていない >> > 場合にフォールバックするであろう）旧来のXIMを使うかと思いますが、 >> > どうされていますか？ pkgでインストールされている場合はデフォルト >> > でビルドされた公式pkgが使用されると思います。 >> > >> > また、portsにせよpkgにせよ、main（latest）とquarterly（現時点では >> > 2025Q1）がある訳ですが、どちらをお使いでしょうか？ >> > >> >> portsnap を用いて随時 main のものを持ってきて >> portmaster で build しています。poudriere は使っておりません。 >> >> mlterm のオプションは以下のようになっています。 >> CAIRO : off >> DOCS : on >> FCITX : off >> FRIBIDI : off >> IBUS : off >> M17NLIB : off >> REGIS : off >> SCIM : off >> SIXEL : off >> UIM : off >> >> 漢字変換は ja-mozc-server-2.23.2815.102.01_26 と >> ja-fcitx-mozc-2.23.2815.102.01_26 を使っております。 >> 環境変数 XIM_PROGRAM に fcitx を設定しております。 > > 普通、Gtk*を使用するアプリケーションであればGtk用に狙った > IME（x11/mltermの場合、依存関係からx11-toolkits/gtk30の > 筈ですのでそれ用）のインターフェースライブラリがあれば > 問題ない筈なのですが、にもかかわらずx11/mltermにもオプション > があるということは、FCITXオプションを有効にしてビルドし直して > みると（良い方向にとは限りませんが）状況が変わるかもしれません。 > ただ、従来記載頂いたオプションで使えていたということが不思議 > ではあります（mlterm側からXIMを要求していたのかもしれませんが）。 > > >> > 私の場合、 >> > ・Auto Raiseは使用している。 >> > ・portsはmainブランチで、stable/14ではpoudriere-develでpkgを >> > ビルドし、srcのmainブランチではports-mgmt/pkg_replaceで更新。 >> > ・Mate DE (x11/mate [6])に出口さんのcompiz-reloaded [7]を追加 >> > して使用。 >> > ・x11/mltermはインストールしておらず、同じx11-tookits/vte3と >> > x11-toolkits/gtk30を使用するx11/mate-terminal [8]を使用 >> > という状況で条件が異なりますが、あえてウィンドウ上方からタイトルバー >> > にマウスカーソルを持っていって、そこから動かさずにキー入力する >> > テストをしてみたところ、症状は再現しませんでした。 >> > >> > 可能性として、依存物の更新にうまく行っていない部分があるかもしれません。 >> > >> >> portmaster -f mlterm として、依存 ports も含めて build しなおしてみま >> したが、状況は改善されませんでした。 > > portmasterは使用したことがないのですが、その手のツール最古参の > portupgradeやその置き換えを狙った（-oオプション等、実装されていない > オプションもありますが）pkg_replaceでは-fオプション単独だと > 【そのports自体】しかリビルドされず、そのportsが依存するものまで > 強制リビルドするには-Rf（または-R -f）オプションを使う必要が > あります。 > portmasterでは設計思想が違うのでしょうか？ > > ＃ 私の古い記憶では、portupgradeがRubyで記述されていることを > ＃ 忌み嫌い、さらに極力システムの運用中に更新をかけてもトラブルが > ＃ 起きにくいようにという配慮でデフォルトで前バージョンのライブラリを > ＃ /usr/local/lib/compat/pkg/以下に退避する仕様はセキュリティ的に > ＃ 悍ましいのでシステムが動作中にクラッシュしようが旧版ライブラリは > ＃ 消滅すべき（ただしどうしてもと言う状況やセキュリティ更新が無い > ＃ ケースも一応考慮して残すオプションをしぶしぶ設ける）という > ＃ （かなり当時の感情も籠もっていますが）一派が開発したのが始まり > ＃ だったと記憶しています。 当時は-fオプションの挙動はportupgradeと > ＃ 同じと言われていた気がするのですが...。 > > なお、portupgrade（や、pkg_replace）では、依存物に変動のない > オプション変更で無駄に依存物まで再構築しないで良いように、と > いう判断だと考えています。 大量の大規模な依存物を抱えたportsで > そのports自体で実装している機能の切り替えのためのオプションを > 変えたら丸ごと強制再構築というのは、特に手元の1台だけでFreeBSDを > 使っている個人ユーザにとっては悪夢です。 > > ＃ ビルド専門でそれ自体はインストールを行わないpoudriereは > ＃ 別の意味で極端で、オプションで強制しない限り、例えば > ＃ 凄まじい数のportsが直接・間接に依存するgettext等が更新されよう > ＃ ものならgettextに依存するportsとそれらに依存するportsを末代まで > ＃ 全部再構築しますし、OSVERSIONが例えば1402001から1402002になった > ＃ （14.2-Release-p1から14.2-Release-p2のレベルの更新） だけで > ＃ フォントやスクリプト等、本質的にOSの更新では再構築が不要なもの > ＃ まで全部再構築しようとします。 確実な安全策ではあるのですが。 > > すみません。 かなり私情が入りました。 > > >> 更に奇妙な以下のような現象も発生しております。 >> >> 1) mlterm を2つ開けておく。 >> 2) 一方のタイトルバーまたはフレームにマウスカーソルを置いてキー入力を >> 行う。当該 mlterm には何も入力されない。 >> 3) マウスカーソルを他方の mlterm に持っていくと、2)で入力を行った >> mlterm に、2) で打ち込んだ文字が入力される。 >> その際、入力される文字は同じだが、順番がランダムに入れ替わることがある。 >> 例えば abc -> bca など。ルールは不明。 > > その挙動からすると、（ランダムに入れ替わるという部分は謎ですが） > キー入力がバッファリングされて入力先が見つからずペンディングされ、 > マウスカーソルが他のmltermのウィンドウの実体部分（タイトルバーや > フレーム以外の実質的なターミナル部分）に移動してフォーカスが移った > ところで吐き出しているように思えます。 > > ところで、ウィンドウを選択するときタイトルやフレームではなく実体の > 部分をクリックされたらどういう挙動になりますか？ センターボタン > によるペーストでなければ基本的に無害とは思うのですが。 > > >> 引き続き情報をお待ちしております。 >> >> 松田 >> >> >> > >> > なお、compiz-reloadedは出口さんのoverlayを >> > >> > https://brew.bsd.cafe/TomAoki/Tips-and-Tricks/src/branch/main/poudriere >> > >> > に（英文ですが）纏めたようなやり方でビルドして使っています。 >> > >> > >> > [1] https://www.freshports.org/x11/mlterm/ >> > >> > [2] https://www.freshports.org/x11-toolkits/vte3/ >> > >> > [3] https://www.freshports.org/x11-toolkits/gtk30/ >> > >> > [4] https://www.freshports.org/devel/glib20/ >> > >> > [5] https://www.freshports.org/accessibility/at-spi2-core/ >> > >> > [6] https://www.freshports.org/x11/mate/ >> > >> > [7] https://github.com/kdeguchi/compiz-reloaded-ports >> > >> > -- >> > 青木 知明 [Tomoaki AOKI] <junch...@dec.sakura.ne.jp> >> > > > -- > 青木 知明 [Tomoaki AOKI] <junch...@dec.sakura.ne.jp> >
