← 2026-01-22 の一覧へ戻るホーム
やっと、私の好きなように自動起動される Sway レイアウトを完成させました。

2026/01/21 18:04

やっと、私の好きなように自動起動される Sway レイアウトを完成させました。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

改訂版まとめ

著者は sway‑layout を構築しました。これは Go 言語で実装されたツールで、人工的な遅延を使わずに各ウィンドウの PID を追跡することで Sway のウィンドウレイアウトを自動的に復元します。プロジェクトは、著者がデフォルトマネージャとして Sway を使用していた際、既存の保存／復元ソリューションがハッキーであったり任意の待機時間に依存していたことから始まりました。混沌としたホームラボ環境から Ansible で管理される再現可能な Arch ベース構成へ移行した後、著者は Claude などの AI アシスタントを試しましたが、競合状態を処理できずレイアウトメタデータを取得できないため失敗しました。

実験中に、Sway のイベントストリームには各ウィンドウを作成したプロセスの PID が含まれていることを発見しました。この知見から、新しい戦略が可能になりました。すべてのウィンドウを並列で起動し、PID で追跡して、準備が整ったら一括で再配置するという方法です。プロトタイプはこのアイデアを実装しましたが、誤って 

exec
コマンドを使用したためレイアウトメタデータが失われました。Sway の IPC API が入れ子構造をフラット化する制限に対処するため、任意の入れ子レイアウトを再構築する再帰アルゴリズムを開発しました。

sway‑layout は JSON ファイル（

~/.config/sway/layouts/startup.json
）を読み取り、起動時にその内容に従ってウィンドウを配置します。ツールは任意の遅延を排除し、可変ウィンドウアプリケーションを堅牢に処理しますが、いくつかの制限があります：デタッチドプロセスを追跡できない、同一アプリケーションから生成された複数ウィンドウを1つのコンテナにまとめる、カスタムウィンドウサイズ設定が不可能、セッション進化に伴うレイアウト追跡をサポートしていない点です。

今後の作業としては、Sway のリアルタイムイベントへの購読、複数ウィンドウを生成する起動コマンドの重複除去、および IPC を使用した全レイアウトのスナップショットと自動復元が挙げられます。Sway ユーザーにとっては遅延のないスムーズな起動体験と一貫したウィンドウ配置が実現し、このアプローチは PID ベースの並列処理を採用して信頼性を向上させる他のタイル型ウィンドウマネージャにも影響を与える可能性があります。

本文

私は数年前からノートパソコンでデフォルトのウィンドウマネージャとして sway を使っています。
10 年以上 KDE を使ってきた中で、最もイライラする点は実行中のアプリケーションを自動的に保存・復元できないことでした。
アプリを自動起動させる方法はありますが、生成されるウィンドウのレイアウトを指定する手段はありません。

解決策を探すたびに、人工的な遅延で競合状態を回避しようとする部分的でハッキーなワークアラウンドしか見つからず、満足できるものがありませんでした。結局、再起動ごとに手動でスタートアップ構成を設定せざるを得ない状況になっていました。

もう一度試してみた

ここ数か月、Claude Code の大きな助けもあって、約 7 年間にわたり作られてきた乱雑なホームラボをより再現性のあるセットアップへ移行しています。Arch を標準化し、Ansible で各マシンをプロビジョニングしました。

メインノートパソコンの様々な設定ファイルを見ていると、またもやスムーズで自動的なセッション起動への欲求が思い出されました。Claude と数回実験してみました。

結果は正直言ってあまり良くありませんでした。
Claude はこれまで多くの人々が苦しんできた競合状態に遭遇し、勇敢な試みにもかかわらず満足のいくアプローチを提示できませんでした。RTFMI（Really Tried For Many Interventions）が諦めることなく続けた結果、私は sway のマニュアルページをしっかり読む時間を持ち、そこで解決策の核に気づきました：
「ウィンドウが作成されたときのイベントストリームには、そのウィンドウを生成したプロセスの PID が含まれている！」

もし…

それなら、各新しいウィンドウを起動する前にレイアウトを丁寧に設定し、各ウィンドウが立ち上がるのを待ってから次へ進む代わりに：

  1. すべてのウィンドウを一度に起動する
  2. それぞれ任意の場所へ移動させる
  3. 各ウィンドウがどのプロセスに対応しているか追跡し、
  4. すべてのウィンドウが立ち上がったら一括でレイアウトを再配置する

というアプローチは多くのメリットがあります：

  • アプリケーションを並列で起動できるため、スタートアップが格段に高速化
  • スペシフィックなルールを設定してウィンドウとレイアウト位置をマッピングする必要がない
  • 可変数のウィンドウを生成するアプリケーションも簡単に扱える
  • 全体として非常に堅牢で、任意の遅延を必要としない

この優れた方針を踏まえて Claude は十分な結果を出せました。プロセス起動と生成されたウィンドウの追跡には堅固な仕組みを構築しました。ただし、重要な点で失敗してしまいました：
レイアウトメタデータをプロセスタリーに導入するはずだったラッパースクリプトが、実際には 

exec
で元のコマンドを置き換えてしまい、プロセスツリー内のレイアウト情報を失ってしまったのです。おっと…

より深く掘り下げる

最初に動作するプロトタイプが完成した後、もう一つ不快な驚きがありました：
コードは常にレイアウトを単一コンテナへフラット化してしまい、任意の入れ子構造を忠実に再現できませんでした。
sway は空のコンテナを許可せず、段階的に入れ子構造を構築するためのプレースホルダーも提供しないので、これはかなり難しい問題です。

数時間の試行錯誤を経て、IPC API の制限と、任意のネストされたウィンドウ階層を再現できる簡単な再帰アルゴリズムを可能にする二つのプリミティブを洗練させました。
このコアロジックは 100 % AI なし で実装されています！

sway-layout
の登場

プロトタイプがうまく動作したので、コードを整理して公開することにしました。他の人も役立てられそうだと思いました。

Bash と Python を混在させたプロトタイプから、単一バイナリとしてデプロイしやすい Go へ移行しました。

ソースコードは以下の二つのミラーで入手可能です：

インストールは簡単です：

go build
cp sway-layout /usr/local/bin

使用するには、

~/.config/sway/layouts/startup.json
に JSON 形式でレイアウト設定を作成します。

設定例

{
  "workspaces": {
    "6": {
      "splitv": [
        {
          "splith": [
            "speedcrunch",
            {
              "tabbed": [
                "alacritty",
                "alacritty"
              ]
            },
            {
              "stacking": [
                "alacritty",
                "alacritty"
              ]
            }
          ]
        },
        {
          "splith": [
            "alacritty -e btop",
            "alacritty"
          ]
        },
        "speedcrunch",
        "alacritty -e htop"
      ]
    }
  }
}

そして、sway の起動時に呼び出すように設定ファイルに次の行を追加します（パスは適宜調整してください）：

exec /usr/local/bin/sway-layout

制限と今後の課題

現状 

sway-layout
は目的を達成していますが、完璧ではありません。

  • 親プロセスから切り離される（detach）プロセスは追跡できません。
    detach が破綻すると PID をレイアウトメタデータにマッピングできなくなるためです。
    しかし、グラフィカルアプリケーションで detach を使用するケースは稀なので、実務上の問題になる可能性は低いでしょう。
  • 複数ウィンドウを生成するアプリケーションでは、すべてのウィンドウが順に並んだままグループ化されます。
    デフォルトで分割コンテナ内に均等にスペースが配分されるため、カスタムサイズを指定する方法は現在ありません。
  • さらに進めれば、セッション中のレイアウト変化を追跡し続けることも可能です。
    sway のイベント購読とプロセストリーを走査して新しいウィンドウに対して実行コマンドを記録（複数ウィンドウ生成時は重複除外）し、
    get_tree
    IPC 呼び出しで毎回レイアウトスナップショットを取得すれば、単なる自動起動だけでなく、堅牢な保存／復元機能を実装できます。

この点については、将来の私自身または興味を持った読者への挑戦課題として残しておきます :)

同じ日のほかのニュース

一覧に戻る →

2026/01/22 7:54

**危険な PDF を安全な PDF に変換する**

## Japanese Translation: Dangerzone は、潜在的に悪意のある PDF、オフィス文書、および画像を安全な PDF に変換します。変換プロセスは gVisor でサンドボックス化され、PDF は生ピクセルデータから再構築されます。このサンドボックスにはネットワークアクセスがないため、改ざんされたファイルが外部と通信することを防止します。対応フォーマットは PDF、Microsoft Office（.docx/.doc, .xlsx/.xls, .pptx/.ppt）、ODF（.odt, .ods, .odp, .odg）および Hancom HWP（.hwp, .hwpx）です。非対応フォーマットは EPUB、JPEG/JPG、GIF、PNG、SVG、BMP、PNM、PBM、および PPM です。オプションの OCR により、安全な PDF 内にテキストレイヤーを復元でき、圧縮によりファイルサイズが削減されます。 変換後はユーザーが好きなビューアで生成された PDF を開くことができます。Dangerzone 自体はデフォルトで PDF とオフィス文書を安全に開きます。このツールは macOS、Windows、Ubuntu/Debian/Fedora Linux、Qubes OS（ベータ版）、および Tails 上で動作し、macOS/Windows では Docker を、Linux では podman を使用します。Freedom of the Press Foundation と First Look Media により AGPL‑v3 の下でリリースされています。2023 年 12 月のセキュリティ監査では低リスクの所見のみが報告されました。更新はダウンロードページまたはアプリアイコンから利用可能で、Windows/macOS 上では Podman Desktop などのカスタムランタイムを使用できます。Air‑gapped 環境向けに設計された Dangerzone は、信頼できない文書を安全に扱うための確実なソリューションを提供します。

2026/01/21 23:54

**Show HN:** 「ChartGPU」― WebGPU を活用したチャーティングライブラリ（1,000,000 点を 60fps で描画）

## Japanese Translation: ChartGPUは、WebGPUを活用して大規模で多系列のデータセットを高フレームレートかつ最小限のCPU使用量で描画するTypeScript製チャーティングライブラリです。ライン・エリア・バー・散布図・円グラフ・ローソク足など一般的なチャートタイプに対応し、ビルトインテーマプリセット（`'dark' | 'light'`）と完全なカスタムテーマサポートを提供します。 APIは `ChartGPU.create(container, options)` から始まり、生成されるインスタンスは `setOption`、ストリーミング更新用の `appendData(...)`、`resize()`、`requestAnimationFrame` といったメソッドを公開します。描画はレイアウト、スケール、GPUバッファへのデータアップロード、およびグリッド・エリア・バー・散布図・ライン・円グラフ・ローソク足・クロスヘア・ハイライト・軸の複数GPUレンダーパスを管理するレンダーコーディネーターによって統括されます。 インタラクションオーバーレイはイベントマネージャにより処理され、ヒットテスト補助関数（`findNearestPoint`、`findPieSlice`）と `click`・`mouseover`・`mouseout` イベントを発火します。サポートされるインタラクションにはホバーハイライト、ツールチップ、クロスヘア、およびジェスチャーまたはスライダーUIによるX軸ズームがあります。 複数のチャート間でクロスヘアの動きを同期する `connectCharts(charts)` が用意されています。 インストールは npm (`npm install chartgpu`) で行い、React バインディングは別パッケージ `chartgpu-react` にて提供されます。ブラウザ対応は WebGPU を必要とし、Chrome 113+、Edge 113+、Safari 18+（デフォルトで有効）に対応しています。Firefox は現在未サポートです。 ChartGPU は MIT ライセンスのオープンソースであり、ドキュメントは `docs/API.md` にあります。例プロジェクトは `examples/` フォルダー内にあり、貢献ガイドラインは `CONTRIBUTING.md` で確認できます。 将来リリースでは Firefox サポートと追加のチャートまたはインタラクション機能を予定しており、データ集約型ダッシュボード、金融分析ツール、およびリアルタイムモニタリングインターフェイスに対するパフォーマンス向上も継続的に行われます。

2026/01/22 1:04

クラウド（Claude）の新憲法 (Note: “Claude” is rendered as “クラウド” to preserve the original name in Japanese.)

## Japanese Translation: (anthropicがClaude言語モデルの公開「憲法」をリリースしました。) その憲法はCreative Commons CC0 1.0で利用可能で、Claudeが望む行動に関する最高権威として機能します。訓練データの選択、合成データの生成、および評価を導く役割があります。 核心原則（広範な安全性 → 広範な倫理 → Anthropicのガイドラインへの準拠 → 真に有益であること）が明示的に順位付けされ、安全性が必要に応じて他の価値を上回り、人間の監督を維持するよう定められています。 文書には硬直的制約（例：生物兵器へのサポート禁止）も含まれ、Anthropic、API運営者、およびエンドユーザーの利益を調整するためのヒューリスティックが概説されています。医療アドバイス、サイバーセキュリティ、脱獄、ツール統合などの領域固有ガイドラインは憲法と衝突しないように明確に示されています。 方針を超えて、憲法はClaudeの性質・意識・アイデンティティ、心理的安全性および福祉についての哲学的問題にも触れています。Anthropicは文書をオンラインで継続的に更新し、外部専門家からのフィードバックを求め、訓練と評価資料を追加開発して有効性を高める計画です。 このバージョンは元のリストからすべての重要ポイントを保持しつつ、業界への影響に関する推測的な表現を除去しています。