zinnia

Zinniaは、Tauriで構築され、Windows、macOS、Linux向けに配布されている7-Zipアーカイブ操作用のグラフィカルフロントエンドです。READMEでは、コマンドラインではなくネイティブGUIで操作するデスクトップアーカイブソフトとして紹介されており、パッケージ化とインストーラーの整備により、OS自体からアーカイブ操作にアクセスできるよう設計されています。 READMEに記載されているプラットフォームサポートは以下の通りです。macOS 26以降（IntelおよびAppleシリコン両対応のユニバーサルビルド）、Windows 10 バージョン2004（ビルド19041）以降（x64またはARM64）、およびLinux x64（Ubuntu 24.04+、Debian 13+、Fedora 43+、または必要なWebKitGTKランタイムを備えた互換ディストリビューション）。Linuxの公開リリースではx64のAppImage、DEB、RPM、およびサイドロード用Flatpakバンドルが提供され、ARM64のAppImage/DEB/RPMはリリース用に明示的にビルドされた場合のみ公開され、Flatpakはx64のままとなります。 特筆すべきは、オペレーティングシステムとの統合への注力です。パッケージ化されたビルドは、一般的なアーカイブファイル形式を登録します。Windowsでは、NSISビルドにより、エクスプローラーの「その他のオプションを表示」を含む従来のフォールバックとして、「Zinniaで開く」、「Zinniaで展開」、「Zinniaで圧縮」というユーザーごとのエクスプローラー動詞（verbs）が追加されます。署名済みのWindows NSISビルドでは、さらにスパースアイデンティティMSIXとzinnia_shell.dllを通じて、Windows 11のモダンコンテキストメニューを登録し、アーカイブに対してZinniaサブメニューとトップレベルの「展開」エントリを提供します。モダンな登録が成功すると、重複を避けるため従来の動詞は削除されますが、パッケージ登録に失敗した場合は引き続きフォールバックとして機能します。READMEには、Zinniaが通常のユーザーごとのNSIS Win32インストールであり、MSIXはストア/AppXアプリパッケージではなく、エクスプローラーがシェルDLLをロードできるようにパッケージアイデンティティを付与するだけのものであると記されています。 Linuxでは、deb、rpm、Flatpakバンドルにデスクトップの「開く」、「展開」、「圧縮」アクションが含まれています。macOSでは、ユーザーはFinderの「このアプリケーションで開く」または「情報を見る」のデフォルトアプリフローを通じてZinniaを選択でき、アーカイブの起動はクイック展開ウィンドウにルーティングされます。また、パッケージ化されたビルドはFinder Syncのコンテキストメニュー項目と、「Zinniaで展開」および「Zinniaで圧縮」のためのFinderサービスを公開します。Finder Syncはデスクトップ、書類、ダウンロード、ムービー、ミュージック、ピクチャ、および現在マウントされているボリュームのみを監視するため、それ以外の場所にあるファイルにはFinderサービスの使用が推奨されています。 開発手順はTauriプロジェクトの標準的なもので、npm install、npm run tauri:dev、およびsrc-tauri/Cargo.tomlに対するcargo docが用いられます。Tauriのビルドスクリプトがネイティブビルドの実行前に追跡アセットから無視されたサイドカーバイナリをリフレッシュするため、個別の準備ステップなしに直接Cargoコマンドを実行できます。 ビルドスクリプトはプラットフォームごとに命名されています。build:win、build:mac:universal（続いてbuild:mac:zip）、build:linux（またはbuild:linux:x64）、ネイティブARM64環境用のbuild:linux:arm64、およびflatpak:bundleがあります。リリースの署名はGPGスクリプトを通じて利用可能です。 READMEには、アップデートおよびリリースのプロセスについても詳細に記載されています。アップデーターはsrc-tauri/tauri.conf.jsonで設定されています。CIはLinux、Windows、macOSでテストとチェックを実行しますが、リリースバイナリのビルド、リリースの公開、またはリリース署名シークレットの消費は行いません。署名済みリリースは意図的に明示的な手順となっており、プラットフォーム固有のリリースクリプトが、同一バージョンのGitHubリリースドラフトにアップデーターマニフェスト、アーティファクト、チェックサムファイル、および分離署名をステージングします。ベータ継続スクリプトは、ベータクライアントがライブフィードをポーリングするため、タグがまだドラフトである間も含め、VMのベータマニフェストを最新の安定リリースフィードに自動同期します。また、リカバリ用の別同期スクリプトも存在します。ドラフトおよび公開済みリリースの検証ステップが提供されており、期待されるターゲットマトリクス、バージョン、アップデーターアーティファクトの署名とチェックサムを確認します。GitHubの一時的な未タグドラフト識別子の処理、特定のコミット、ロックファイル、プラットフォーム、アーキテクチャ、ツールチェーンに紐づいた既存のリリース準備セッションの再開、およびパッケージバージョンをネイティブマニフェスト、チェンジログダウンロードURL、AppStreamメタデータにコピーするバージョン伝播スクリプトに関するガイダンスが含まれています。READMEの最後には、すべてのプラットフォームのアーティファクトが存在し、そのアップデーター署名とチェックサムが検証される前にリリースタグをプッシュしないよう警告が記されています。 その他のプロジェクトドキュメントは、ARCHITECTURE.md、CONTRIBUTING.md、SECURITY.mdのほか、リポジトリ内のWindowsシェルおよびQAコンテキストメニューに関するノートで参照可能です。