appsweets akahuku labs.

太古の昔はコンピュータに繋がってるキーボードはひとつだけで、しかも静的に接続されていたが今はそうではなく複数の、しかも異なるレイアウトのキーボードを動的に繋げたり外したりすることができる…のだが、ソフトウェア側でそれに対応しているのかはよく分からない。OSのキーボードの設定とかで接続されているキーボードごとに割り当てるレイアウトを決められるとかそういうものは見たことがない。 さて調べてみたところkeydというものがあり、ちょっと試している。上述の問題はデバイスIDを明示することで少し解決できる。それ以外にも非常に自由度の高いリマップを行える。 ちなみにちょっとしたリマップの機能はgnome自身も持っている（正確には、リアルタイムでsetxkbmapに対する定義を行うような機構だと思う）のでkeydをメインで使う場合はgnomeのそれは触らない方がよいかもしれない。すなわち、org.gnome.desktop.input-sourcesのxkb-optionsを単に空（[]）にする。 $ gsettings set org.gnome.desktop.input-sources xkb-options “[]” もしこれに何か定義されている場合、例えば['ctrl:swapcaps', 'ctrl:ctrl_ralt', 'compose:menu']と言った値が入っている。そのまんま、setxkbmapのオプションに与えるアレの配列である。なおアレのリストはsetxkbmap -print -v 10で出力されるrulesファイルの中に書いてある。たとえば/usr/share/X11/xkb/rules/evdevとかだ。 インストール いろいろ調べるとkeydのインストールはgithubからcloneしてmakeみたいなことを指示している文書が多いが、masterブランチは開発中のものなのでcloneするのはstableとタグが付けられたコミットの方がいい（とreadmeに書いてある）。その他いくつかのディストロについては一応パッケージが用意されている。以下ubuntuの場合。ubuntuでは現在ppaを経由することになっているが、とても便利なツールなのでそのうち標準のリポジトリに入る気がする。 $ sudo apt-add-repository ppa:keyd-team/ppa $ sudo apt update $ sudo apt install keyd これでインストールされる実行形式は、そのままだとあまりにジェネリックすぎるためか、keyd.rvaiyaという名前になっていた。man の項目も同様にman 1 keyd.rvaiya。 インストール後はsystemdのシステムサービスが登録されているのでそれを有効にすると起動時から有効になる。 $ sudo systemctl enable keyd … Continue reading

Chromeが135.0.7049.95に更新されたのだが、これに対して–gtk-version=3を与えると何かが盛大に壊れ、ページのkeydownまわりとか、あるいはコンテンツスクリプトからバックグラウンドへのメッセージングとか、とりとめなく色んなところがおかしくなるようだ。

ところでEmacsのキーバインディングを実装すると言っても、当然ながらほんの一部であってそんな大したものではない。ただし実装しておーこれは意外に便利かも？　と思ったものもある。 EmacsはM-/ でdynamic abbrevという機能が働くが、これを似たようなものを実装した。例えば入力中にサジェストが表示されるサイトなんかでM-/を押すとそのサジェスト候補が自動入力される。候補が複数ある場合はそのままM-/を押していけば順繰りに入力される。 それからこれはEmacsとは全然関係ないが、カーソル位置の四則演算式をその結果で置き換える機能をM-cに割り当てた。また、C-mを押すと、入力している要素が属するフォームをサブミットするようにした。

そういうわけで、月末までEmacsバインディングのないChromeで過ごさざるを得なくなったわけなのだが、当然の成り行きながらCtrl+HやCtrl+Wをうっかり押してしまいぎょえー！となるアクシデントが頻発して気が狂いそうになっている。どうにかならないの。 Emacsバインディングと言えば、過去にjavascriptレベルで実装したことがある。赤福プラスは *.2chan.net 上でのみ、Search Cobb は検索文字列入力欄のみEmacsバインディングが有効になっている。ちなみに両者の違いは、前者がフクザツな作り（各ハンドラが非同期でもよいとか、Firefoxでも動くとか）で後者がシンプルということだ。 この実装済みながら、適用範囲が限られているものをwebページ全体に押し広げればなんとかならないだろうか。 ということで、SearchCobbのそれを拡張することにした。 言うまでもないがこのソリューションだとアドレスバー、拡張が管理するドキュメント、Webコンポーネントの中身などには効果が及ばないため完全ではないのだけど、しかしないよりははるかにマシである。 ところでこのgtk4でgtk-key-themeが効かなくなっちゃう問題ってXとかで検索しても特にホットな話題でもなんでもないみたいなんだけど、そういうものなんだなあ…。

Chromeが135.0.7049.84に更新された…のだが、gtk-key-themeで定義しているキーバインディングが効かなくなった。 どうやらそのバージョンあたりからgtk4を優先的に使用するようになったらしいのだが、そもそもgtk4にキーバインディングの仕組み自体がないのだそうだ。 gtk3を優先的に使用させる方法はないのか？　と探してみたが、–gtk-version=4 というコマンドラインスイッチはあるのにこれを3にしてもそうならない。strace -e openat /opt/google/chrome/chrome 2>&1 | grep gtk などとやっても依然としてgtk-4.0なんちゃらが読み込まれる。 このgtkのバージョン指定の問題は、136で解決されるそうなのでとりあえず今月末あたりにそれがリリースされれば、Chromeの起動時に –gtk-version=3 を与えてやることで再びキーバインディングが有効になるだろう。たぶん。 しかしこれもgtk3がサポートされる期間の話なので油断はできない。そもそもどうしてgtk4でキーバインディングの仕組みが削除されたのか？　と言えば、この仕組みがcssの定義に乗っかってるからであって、キーバインディングの定義ってcssの範疇じゃなくない？　消してよくない？　という話になり、そして特に代替もないままとりあえずドロップされたという経緯のようだ。ドロップされたのが6年前で、今に至るまで代替機能は開発されていない。

最近Ubuntu 24.04.1 LTSに上げたわけなのだけど、 その半透明機能が効かなくなるという現象が発生して困っている。たとえばgnome-terminalとかだ。端末の背景がスケスケの助になるのはカッコいいだけではなくちゃんと実用的なので、そうならないと日々の作業が直接的に不便になって困る。 調べてみるとこれはmutter（Waylandにおけるコンポジタ─すべてのウィンドウとデスクトップのビットマップを合成するプログラム）の仕様がそう変わったから、のようだ。フルスクリーンの状態ならそのアプリケーションが全てのピクセルについて責任を持とう、みたいなポリシーなんだろうか。https://gitlab.gnome.org/GNOME/mutter/-/issues/2520 その理屈自体は筋が通っているかもしれないが、しかし実際影響が大きすぎるので、なんか代替の仕様が必要なんじゃない？みたいな話にもなっている…が、あまり動きは活発ではない。https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/116 とりあえずのワークアラウンドとしてはフルスクリーンではなくウィンドウを最大化すればいいわけなのだが、そうするとタイトルバーが無駄にピクセルを消費してとても邪魔なのである。これをどうにかしたい。 ここで、探してみるとウィンドウを最大化したときタイトルバーを隠しますと謳うgnomeエクステンションがあったりするのだけど、入れてもそうならない。gnomeエクステンションの仕様はちょくちょく破壊的な変更を伴うのか動作するバージョンの範囲が狭いものが多いのであまりに当てにならない。https://github.com/hardpixel/unite-shell ということで別の何かを探してみると、Black Boxという端末エミュレータがある。https://gitlab.gnome.org/raggesilver/blackbox新しい端末を作りました！ってお出しされた場合、肝心の端末のコア部分が既存のライブラリなのか、それを含めて自作なのかで評価の軸が変わってくる。このアプリケーションの場合コアはlibvteなので、主に評価すべきはそのガワの部分である（ただしflatpakパッケージとして公開されていて、最新のlibvteを内包している…という工夫がされている。そのため、sixelも使えてしまう）。 で、ガワの部分だけどタイトルバー（とタブバー）を隠すというオプションがあり、その通りに動作する。また、タイトルバーがありそうな位置にマウスポインタを持ってくるとニュッと出てくる動作にすることもできる。おー。いいじゃん。これにしよう。 …となりそうなのだけど、別の所から問題が出てくる。前述の通りこれはflatpakパッケージで、起動中flatpak-session-helperなるプログラムも漏れなく動いているわけなのだが、何か知らないがこれが常時数%〜十数%のCPUパワーを消費してマシンのファンをファンファンさせるのであった。なにこれぇ。https://github.com/flatpak/xdg-dbus-proxy/issues/51 しかし原因がBlack Boxなのか、flatpak-session-helperなのかよく分かっていない。Black BoxにはNightly版もあるのでこれを使うようにして様子を見てみよう。

たいていのブラウザに組み込みのページ内検索機能があり、Chromeにもある。ただし、ブラウザがもっと小規模なアプリケーションだった頃からある機能のせいか微妙に素朴な動きしかしてくれない。例えば標準で正規表現が使えると嬉しいのだけど、できない。ページの密度が高くなってくると単に色でハイライトされたキーワードを見つけづらかったりするのも不便。検索ダイアログをEscapeでしか閉じられないのもめんどう。 そこで必要な機能を備えた拡張を作るかということになる。もちろん正規表現でページ検索できる拡張はすでにたくさんあるのだが…例えば現代だとそこかしこに絵文字が使われてるわけだが、最新の絵文字は複数のコードポイントから形成されてたりする。つまり検索を行う拡張側でも正確な書記素クラスタの認識ができないとハイライト処理などが盛大に壊れたりする可能性があり…実際いくつか試してみたところ盛大に壊れる。 また、正規表現によるページ内検索を実装する場合、要素を走査して要素ごとに検索を行う場合とそれ以外が考えられる。前者だと パンケーキとどら焼きって<b>ぶっちゃけ同じ</b>だよね のようなテキスト全体を検索することができない。既存の拡張は、全て試したわけではないが、だいたい半々くらいに分けられると思う。シンプルな実装の方が堅牢だし応答もよいだろうから明確に優劣があるわけではないのだが、まあできるのなら要素をまたいだ検索が可能な方がよい。 ついでに言うと migemo 検索ができると若干嬉しい。若干というのは、Chrome で migemo 検索というのは10年くらい前にはそういう拡張があったのだが、知らないうちに公開停止になっていて、しかもそれが特に話題にもなってないっぽくて、特に代替の拡張も登場しないまま10年経っているという現実が引っかかるからである。要するに非常にニッチにしか刺さらなくて、あんまり広い需要はないし売りにもならないのかもしれない。まあ個人的にはあれば嬉しい。 以上の要件を勘案すると、じゃあ新しいの作るかーということになる。 ＊ ＊ ＊ というわけで、作った。

そういえばずっと以前にブラウザをvimっぽくする拡張の評価をいろいろして、最終的にcVimを選択したことがあった。それでずっとcVimを使っていたのだけど、メンテされなくなって随分経ち、いろいろと不具合が目立ってきたので別の何かに乗り換えることにした。 乗り換え先はタイトルの通りVimiumだ。VimiumはcVimに比べると という明確なconsがあるが、それ以外はまあ何とかなる。軽いしよくできている。今までありがとうcVim…！

サムネイルを表示するlsというものを作ったのだけど、サムネイル、つまりsixel形式の画像データをどの端末エミュレータでも表示できるわけではないので、現時点では対応できる端末が限られている。 例えばUbuntuに最初から入ってる端末はlibvteというgnomeのコンポーネントを利用してその機能を提供しているのだけど、現時点ではsixelを表示できない（ただし、libvteのソースにはすでに対応コードが入っていて鋭意テスト中のようなので使えるようになるのは時間の問題だろう）。 そんなわけで、sixelが使える別の端末を探したところ、WezTermがよくできているようなので常用を試している。ちなみに、インストールする手段が複数提供されていてflatpak経由がかんたんなのだが、flatpakアプリケーションであるが故の不具合がちらほらあってハマる（マウスポインタがちょくちょく消えるとかfcitx5がよく壊れるとかluaで利用できるAPIが一部正しく動作しないとか）のでaptで入れるかappimageを利用するのがいいだろう。豆知識。 あと数年したら端末で画像を表示することが当たり前になって黒い背景に文字だけの時代は過去のものになるよ。マジで。

以前書いたChromeの拡張の中にTabQueueというものがある。 これは主に3つの機能を備えていて: タブをアクティブにした順番を覚えてくれる。あるタブを閉じた場合、その前にアクティブだったタブを再度アクティブにする。これはPresto Operaの同機能の移植である タブを開いたとき、自動的にそれをフォアグランドにする グローバルなホットキーをひとつ定義でき、それを押すとアクティブタブオーダーをポップできる。デフォルトではCtrl+,である。例えば右端のタブでyoutubeを開いて何かの動画を流しているがボリュームの調整だとか、何かちょっとした操作をしたいとする。そんな場合はg$で右端のタブに飛び（これはcVImの機能だが）、何か動画を操作し、Ctrl+,を押すと元のタブに戻れる。 というわけでかなりニッチな個人的ニーズを満たすものではあるがそれだけに欠かせないものであり毎日あたり前に使っている。 で。 先日Googleからメールが来て曰く、「TabQueueはウェブストアのポリシーに違反しています！説明に表記されている機能を提供していません！14日以内にアクションがない場合はウェブストアから削除される可能性があります！」…というのである。 何言ってんだおめえぶっころがすぞ…という感じである。何かよく分からないので無視している。ちなみにすでに14日以上経過している。