永遠のドックを求めて – Lambdock

永遠のドックを求めて - lambdock 推定読書時間: 18分 執筆日: 2026年8月28日 これはlambdockの物語です: https://codeberg.org/jjba23/lambdock lambdockは、現代的で、非常にハック可能で、Waylandネイティブなデスクトップドックアプリケーションです（C言語とGuile Scheme + GTK4）。REPLも備えています。 ヘビーなコンピューターユーザーとして、デジタルライフを楽しみながら一日の大半を過ごし、見た目の美しさとワークフロー最適化を愛好する私にとって、究極のデスクトップドックは長年の夢でした。 ここに、lambdockの物語があります。Waylandネイティブで、無限のハック可能性、流体的な物理アニメーション、瞬時の応答性、そして「自由」としての自由を備えたこの獣の物語です。 しかし、そこに至るまで、私はまずその考え方、失敗したプロトタイプの墓場、上り坂の戦い、そしてGTK4 Cランタイムの最終的な征服、そして生き生きとした対話型Lispの心臓の埋め込みへと、あなたを連れて行きます。 永遠のドックを求めて 長年、デスクトップGNU/LinuxユーザーがWaylandに移行する際に直面した、繰り返される悲劇がありました。それは、Cairo-DockやPlankのような象徴的で深くハック可能なドックを失うことでした。 とはいえ、2026年現在、これらのプロジェクト（および他のプロジェクト）はWayland互換性を持つために多大な努力をしており、それは素晴らしいことです。 WaybarやEWWのようなバーエンジンはステータス表示に優れていますが、これらのヘビー級（そしてmacOSも）に匹敵する真のアプリケーションドックには、レイアウト配置、動的なウィンドウ追跡、自動非表示、そしてアニメーションのための流体的なホバー物理学のユニークな組み合わせが必要です。 lambdockの物語は、多くの意味で回復力の物語です。ドックを（さまざまな方法で）構築しようと、いくつの試みをしたか覚えていないほどです。 私のビジョンが具体的な現実になる前に、どれだけのパラダイム、アイデア、PoCが崩壊したか、ほとんど知りませんでした。 2026年7月30日、私は啓示を受け、lambdockの構築に着手しました。macOSやCairo-Dockの体験を再現するだけでなく、実行時の完全な検査可能性、ハック可能性、そしてLispの啓蒙によってそれを超えるWaylandネイティブのデスクトップドックです。 私はGTKが2026年現在、GNU/Linuxおよびその他のプラットフォームにとって最高のUIツールキットだと考えています。そのため、Qtなども検討しましたが、私にとってその選択は非常に明確でした。GTKが常にトップでした。 多くのPoCの残骸の後、ベッドでHackerNewsを読んでいたとき、ふとある考えが頭をよぎり、突然、絶対的な明晰さが訪れました！なぜ、GTKが書かれている言語、つまりC言語で、idiomaticな最新のGTK4を使わないのか？ああ、待てよ、その言語にはlibguile.hがあり、Lisp（GNU Guile Scheme）との素晴らしい相互運用性があり、双方向のバインディングと通信を可能にします。 これは、私の好きな言語（GNU Guile）についてもっと学び、GTKとのシームレスなセットアップとネイティブな超パフォーマンスを可能にするかもしれない、このウサギの穴に飛び込むのはどうだろうか？ そこで私は、Emacsに大いに触発されて、ベッドの中でlambdockの設計を心に描きました。 プログラムを動かす強力で小さなCコア、レンダリング、グラフィックス、低レベルの詳細、そして実行時には全体の心臓と脳となる組み込みのGNU Guile Schemeエンジン。 このアーキテクチャは、対話型ソケットREPL制御、Lispメタプログラミングマクロ、動的なマルチドックのスプーニング、ネイティブWaylandの外部トップレベルウィンドウ追跡、そしてフレームクロック駆動のホバーアニメーションをユニークに提供します。 プロトタイプの墓場 lambdockへの道のりは、最終的に放棄された野心的な概念実証（PoC）で舗装されていました。 私は、低レベルのディスプレイサーバー制御を犠牲にすることなく、迅速な開発という夢を追い求め、いくつかの言語、アプローチ、フレームワーク、アーキテクチャ実験を渡り歩きました。 この探求は当初、Guile GIおよびその他の既存のGuile GTKバインディングを使用した、純粋な100% Lispアーキテクチャを目指していました。 しかし、このビジョンは、まばらなドキュメントと不可解なバインディングレイヤーの下で崩壊しました。 GTKの命令型オブジェクト指向状態と関数型Schemeパターンをブリッジすることは、常にアーキテクチャ上の摩擦を生み出し、小さなコミュニティは、あらゆるバインディングのエッジケースがデッドエンドと長いウサギの穴へのダイブになることを意味しました。 Python + GTK3/4を試したところ、迅速なプロトタイピングと巨大なライブラリエコシステムが得られましたが、深刻なリアルタイムパフォーマンスの限界にぶつかりました。 シングルスレッドのボトルネックとグローバルインタプリタロック（GIL）のスタッターは、カスタムCコードでバックアップされない限り、流体的なスライドアウトアニメーションを台無しにしました。 それはまた、全体をC言語で書くことも考えるきっかけになりました。 重いメモリフットプリントと壊れやすいIPCメカニズムと相まって、ランタイムは低遅延デスクトップドックには重すぎ、予測不可能すぎることが判明しました。 Rust、GTKバインディング、カスタムコンポジタIPCを使用した試みは、メモリ安全性と恐れのない並行性を約束しましたが、深刻な冗長性とバインディングの摩擦をもたらしました。 Rustの非同期イベントループとGTK4のメインスレッドとの不一致は構造的な問題を引き起こし、ボロチェッカーはGTKと私がサポートしたい動的機能で作業する際に本当に面倒なものでした。一方、リフレクションの欠如は、ライブで対話的なLisp REPLを（簡単に）埋め込む道を完全に閉ざしました。 JavaScript/NodeとLayer Shellを使用して、使い慣れたウェブスタイルのスタイリングと非同期I/Oをターゲットにした最後の試みを行いました。 しかし、これはリソース消費の肥大化、低レベルのWaylandプロトコルとの統合の悪さ、そしてLisp拡張性のための明確なパスの欠如に悩まされ、すぐに放棄されたプロトタイプの墓場にその場所を得ました。 鉄の骨格、Lispの魂 C + GTK4 + gtk4-layer-shellは、ネイティブWaylandサーフェスコントロールの紛れもないチャンピオンです。 Cは、生のスピード、ゼロコストのGLib統合、メモリレイアウト効率、完璧なWaylandスキャナープロトコル生成、そして最高のGTKドキュメントを提供します。 GNU Guile Scheme (libguile) は、究極のランタイムマインドです。 静的で死んだJSONやTOMLファイルでドックを設定する代わりに、Lisp (Guile Scheme) をlibguile.h経由で埋め込むことで、ドックは生き生きとしたLispの心臓を持ち、無限に拡張可能なプログラムになります。 /* Cがmain.cでLispエンジンをブートする瞬間 */ int main(int argc, char **argv) { #ifdef DEFAULT_GSK_RENDERER g_setenv("GSK_RENDERER", DEFAULT_GSK_RENDERER, FALSE); #endif /* GNU Guile Schemeエンジンをブートし、inner_mainに制御を譲る */ scm_boot_guile(argc, argv, inner_main, NULL); return 0; } CのGTK4メインループ内に直接libguileをホストすることで、lambdockは私が聖杯と考えるものを達成します。GNU Emacsのように、無限の拡張性、レンダリングとアニメーションのための妥協のないネイティブパフォーマンス、そしてユーザー設定とライブREPL検査のためのLispのメタプログラミング超能力です。 語源 lambdockという名前は、以下の言葉遊びを組み合わせています。 Ship Docks ⚓ コンテナとアプリケーションが安全にドッキングする場所。 lambda λ 関数型プログラミングの式とLispの啓蒙。 Lambs 🐑 （穏やかで、ふわふわで、軽量で、清潔な）。 Docks デスクトップUIコンポーネントとして（例: Plank, Cairo-Dock, macOS Dock）。 lambdockは、十字架と赤い旗を持った神の子羊、アグヌス・デイをプロジェクトロゴとして採用しています。 このドックを使うことは、エンリケ・イグレシアスの体験のような、ほとんど宗教的な体験だと言えるでしょう。 マルチコンフィグ & マルチドックインスタンス lambdockは、組み込みのマルチドックオーケストレーション機能を備えています。 単一のドックバーに限定されるのではなく、異なる画面端やモニターにわたって、複数の独立したドックを同時に実行できます。 自動ディレクトリ監視: lambdockは、~/.config/lambdock/ を監視し、settings.scmまたはsettings-*.scm（例: settings-left.scm, settings-bottom.scm）に一致するファイルを検出します。 各設定ファイルは、独自の分離されたLambdockState、位置（dock-position）、テーマ（dock-theme）、モニターターゲット（dock-monitor）、およびアイテムランチャーレイアウト（dock-items）を定義します。 動的なスプーニング: 新しいsettings-2.scmファイルを作成すると、画面上に新しいドックバーが即座にスプーニングされます。 動的なホットリロード: いずれかのsettings-*.scmファイルを編集すると、他の実行中のインスタンスを再起動したりちらつかせたりすることなく、その特定のドックインスタンスがホットリロードされます。 動的な破棄: settings-*.scmファイルを削除すると、対応するドックウィンドウが安全にダウンし、破棄され、アプリケーションをクラッシュさせることなくWaylandハンドルとGTKウィジェットが削除されます。 lambdockはどのシステムをサポートしていますか？ lambdockはGNU/Linuxを最優先としています