Haiku を始めて XNUMX 日目: リソース、アイコン、パッケージの内部

TL; DRA: Haiku は PC 向けに特別に設計されたオペレーティング システムであるため、他のオペレーティング システムよりも優れたデスクトップ環境を実現するためのいくつかのトリックがあります。 しかし、それはどのように機能するのでしょうか?

最近 Haiku という思いがけない良いシステムを発見しました。 特に Linux デスクトップ環境と比較した場合、そのスムーズな動作には今でも驚かされます。 今日はボンネットの下を見ていきます。 より深く理解するために必要な場合は、オリジナルの Macintosh、Mac OS X、および Linux デスクトップ (freedesktop.org の XDG 標準) と比較します。

ELF ファイル内のリソース

昨日、IconOmatic が ELF 実行可能ファイルの rdef リソースにアイコンを保存できることを知りました。 今日はそれが実際にどのように機能するかを見ていきたいと思います。

資力？ 見積もり から ブルース・ホーン、Macintosh Finder のオリジナルの作者であり、Macintosh Resource Manager の父です。

私は従来のコーディングの厳格な性質を懸念しています。 私にとって、アプリケーションがコード内で凍結され、動的に何も変更できないというアイデアそのものが、最もワイルドなアイデアです。 実行時に可能な限り変更できるようにする必要があります。 もちろん、アプリケーションのコード自体を変更することはできませんが、コードを再コンパイルせずに何かを変更することはできますか?

オリジナルの Macintosh では、これらのファイルに「データ セクション」と「リソース セクション」があり、アイコンや翻訳などの保存が非常に簡単になりました。 実行可能ファイル内。

Mac ではこれが適用されます 再編集、リソースを突然編集するためのグラフィカル プログラムです。

オリジナルの Macintosh での ResEdit

これにより、アイコンやメニュー項目、翻訳などを編集できるようになりました。 十分に簡単ですが、それでもアプリケーションとともに「移動」します。
いずれにせよ、このアプローチには大きな欠点がありました。それは、Apple ファイル システムでしか機能しなかったということです。これが、Apple が Mac OS X に移行するときに「リソース セクション」を放棄した理由の XNUMX つでした。
Mac OS X では、Apple はファイル システムに依存しないソリューションを望んでいたため、(NeXT からの) パッケージという概念を採用しました。これは、ディレクトリではなくファイルのように、ファイル マネージャーによって「不透明なオブジェクト」として扱われるディレクトリです。 形式のアプリケーションを含む任意のパッケージ .app とりわけ、ファイルを持っています Info.plist (Apple の JSON または YAML に類似したもの) にはアプリケーションのメタデータが含まれます。

Mac OS X アプリケーション パッケージの Info.plist ファイル キー。

アイコン、UI ファイルなどのリソースは、ファイルとしてパッケージに保存されます。 実際、NeXT ではこのコンセプトがそのルーツに戻りました。

1.0 年の NeXTSTEP 1989 上の Mathematica.app: ターミナルではファイル ディレクトリとして表示されますが、グラフィカル ファイル マネージャーでは単一のオブジェクトとして表示されます。

Haiku のベースとなっている BeOS に戻りましょう。 開発者は、PEF (PowerPC) から ELF (x86) (Linux で使用されているものと同じ) に移行する際に、ELF ファイルの末尾にリソース セクションを追加することにしました。 これは、独自の適切な ELF セクションを使用せず、単に ELF ファイルの末尾に追加されました。 プログラムの結果として strip そしてそれを知らない binutils の他の人々はそれを切り捨てます。 したがって、BeOS 上の ELF ファイルにリソースを追加した後は、Linux ツールでそのファイルを操作しないことが最善です。

そして今、俳句で何が起こっているのでしょうか？ 基本的には、多かれ少なかれ同じです。

理論的には、ELF の目的のセクションにリソースを配置することが可能です。 irc.freenode.net の #haiku チャンネルの開発者によると、次のようになります。

ELF を使用すると、このセクションはより意味のあるものになるでしょう...そうしない唯一の理由は、BeOS でそれを行ったからです。」
そしてそれを今変える必要はない。

資源管理

リソースは、構造化された「リソース」形式で記述されます。実際、これは、サイズとその内容を含むリソースのリストです。 思い出した ar形式.
Haiku でリソースを確認するにはどうすればよいですか? ResEditのようなものはありますか？
による ドキュメンテーション:

実行可能ファイルを次のようなプログラムにドラッグ アンド ドロップできます。 リソース提供者。 ターミナルに移動してコマンドを実行することもできます listres имя_файла.

Resourcer は HaikuDepot にありますが、私にとってはクラッシュします。

では、ELF ファイル内のリソースはどのように管理するのでしょうか? 使用する rsrc и rdef. rdef ファイルは以下に収集されます rsrc。 ファイル rdef プレーンテキスト形式で保存されるため、作業がはるかに簡単になります。 ファイル形式 rsrc ELF ファイルの最後に追加されます。 遊んでみましょう:

~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
    rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
    rc [options] [-o <file>] -d <file>...Options:
    -d --decompile       create an rdef script from a resource file
       --auto-names      construct resource names from ID symbols
    -h --help            show this message
    -I --include <dir>   add <dir> to the list of include paths
    -m --merge           do not erase existing contents of output file
    -o --output          specify output file name, default is out.xxx
    -q --quiet           do not display any error messages
    -V --version         show software version and license

プログラムを使用できます xres 確認および管理するには:

/> xres
Usage: xres ( -h | --help )
       xres -l <file> ...
       xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

よし、やってみようか？

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type           ID        size  name
------ ----------- -----------  --------------------
'MIMS'           1          36  BEOS:APP_SIG
'APPF'           1           4  BEOS:APP_FLAGS
'MSGG'           1         421  BEOS:FILE_TYPES
'VICN'         101        7025  BEOS:ICON
'VICN'         201          91  kActionBack
'VICN'         202          91  kActionForward
'VICN'         203         300  kActionForward2
'VICN'         204         101  kActionStop
'VICN'         206         243  kActionGoStart
'MSGG'         205        1342  kActionGo
'APPV'           1         680  BEOS:APP_VERSION

リソースと形式の詳細 rdef あなたは読むことができます ここで.

標準リソースタイプ

リソースには何でも入れることができますが、いくつかの標準タイプが定義されています。

• app_signature: 開いているファイル、スタートアップ、IPC などに一致するアプリケーションの MIME タイプ。
• app_name_catalog_entry: アプリケーション名は通常英語であるため、ここで翻訳された名前が配置される場所を指定すると、必要に応じて、異なる言語のユーザーに翻訳されたアプリケーション名が表示されます。
• app_version: まさにあなたが思っていた通りです
• app_flags: を示します registrar アプリケーションの扱い方。 目に見える以上のものがあると思います。 たとえば、次のようなものがあります。 B_SINGLE_LAUNCHこれにより、ユーザーが要求するたびにシステムが新しいアプリケーション プロセスを開始します (Linux 上のほとんどのアプリケーションで同じ原理が使用されます)。 食べる B_MULTIPLE_LAUNCH、プロセスが実行される原因となる 各ファイル。 ついにそこに B_EXCLUSIVE_LAUNCHこれにより、ユーザーがどれだけ頻繁にプロセスを開始しても、システムは一度に XNUMX つのプロセスのみを強制的に開始します (たとえば、これが Linux 上の Firefox の起動方法です。同じ結果は、次の関数を使用する Qt アプリケーションでも達成できます) QtSingleApplication）。 を使用したアプリケーション B_EXCLUSIVE_LAUNCH ユーザーが再度実行しようとすると通知されます。たとえば、ユーザーが開きたいファイルのパスを取得します。
• vector_icon: アプリケーション ベクター アイコン (BeOS にはベクター アイコンがなく、ほとんどのアプリケーションの実行可能ファイルには代わりに XNUMX つのビットマップ アイコンがありました)。

もちろん、任意の ID とタイプを持つリソースを追加し、クラスを使用してアプリケーション自体または他のアプリケーションでそれらを読み取ることができます。 BResources。 まずは、アイコンの魅力的なテーマに注目してみましょう。

俳句風のベクトルのアイコン

もちろん、Haiku が最適なアイコン形式を選択しただけではありません。この部分における Linux デスクトップの状況は理想からはほど遠いです。

me@host:~$ ls /usr/share/icons/hicolor/
128x128  256x256  512x512           index.theme
160x160  28x28    64x64             scalable
16x16    32x32    72x72             symbolic
192x192  36x36    8x8
22x22    42x42    96x96
24x24    48x48    icon-theme.cache

これを見れば、この作品が何であるかがすぐにわかります。

もちろん、ご覧のとおり、ベクトル アイコンを含むスケーラブルなアイコンもあります。 それではなぜ他に何かがあるのでしょうか？ 小さなサイズでベクター グラフィックスを描画すると、理想的な結果が得られない可能性があるためです。 さまざまなサイズに最適化されたさまざまなオプションを用意したいと考えています。 Linux デスクトップ環境では、これはファイル システム全体にさまざまなサイズのアイコンを散在させることによって実現されます。

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

Firefox には異なるバージョンという概念がないことに注意してください。 したがって、システム内に複数のバージョンのアプリケーションが存在する状況に適切に対処することはできません。

バージョンごとに異なる Firefox アイコン。 これまでのところ、さまざまな松葉杖がなければ Linux でこれを処理することは不可能です。

Mac OS X はもう少し洗練された処理を行います。

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

ファイルがXNUMXつあることがわかります firefox.icns パッケージの中に Firefox.app、すべてのサイズが含まれるため、同じアプリケーションの異なるバージョンでは異なるアイコンが表示されます。
ずっといい！ アイコンはアプリケーションとともに移動し、すべてのリソースは XNUMX つのファイル内にあります。

俳句の話に戻りましょう。 驚くべき決定であり、例外はありません。 によると ドキュメンテーション:

小さなサイズと高速レンダリング向けに高度に最適化された特別な HVIF フォーマットが開発されました。 したがって、私たちのアイコンの大部分は、ビットマップや広く使用されている SVG 形式よりもはるかに小さいです。

そして、それらは依然として最適化されています。

他の形式と比較した HVIF のアイコン サイズ。

一桁違います！

しかし、魔法はここで終わりません。 同じ HVIF はベクトル形式であっても、表示されるサイズに応じて異なる詳細レベルが表示される場合があります。

レンダリング サイズに基づいたさまざまな詳細レベル (LOD)

次に欠点について説明します。SVG を取得して ImageMagick に放り込んで終了することはできません。HVIF 形式でアイコンを作成するには、いくつかのサイクルを実行する必要があります。 ここで 説明。 ただし、IconOmatic は SVG のインポートが非常に不完全な場合があります。 SVG 詳細の約 90% はある程度の確率でインポートされますが、残りの 10% は手動で構成および変更する必要があります。 HVIF がどのように魔法を発揮するかについて詳しく読む 1ことができます ブログで リー・ガンソン

アプリケーションへのアイコンの追加

作成したパッケージにアイコンを追加できるようになりました 前回受け取ったすべての情報を考慮して。
そうですね、今のところ「Hello World」QtQuickApp 用に独自のアイコンを描きたいわけではないので、Qt Creator からアイコンを取り出します。

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator  -o /Haiku/home/QtQuickApp/QtQuickApp  -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator

アイコンがコピーされたことを確認してみましょう。

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

見た目は良いのですが、新しいアイコンをコピーしても表示されないのはなぜですか?

コピーされた VICN:101:BEOS:ICONs は、現在ファイル マネージャーでアプリケーション アイコンとして使用されていません。

私は何を取りこぼしたか？

開発者コメント:

ファイルを作成する必要がある rdef すべてのリソースを指定してコマンドを実行します rc имя.rdef、これによりファイルが作成されます .rsrc。 次に、コマンドを実行する必要があります resattr -o имя_бинарника имя.rsrc。 少なくとも、同様のコマンドを使用してアイコンをスクリプトに追加します。

そうですね、私が作成したかったのは属性ではなくリソースでした。 まったく混乱しています。

ファイルシステムを使用したスマートなキャッシュ

ELF 属性を開いて読み取るのが遅い。 上でも書きましたが、アイコンはファイル自体にリソースとして書き込まれます。 この方法はより信頼性が高く、別のファイル システムへのコピーを続けることができます。 ただし、ファイル システム属性にもコピーされます。たとえば、 BEOS:ICON。 これは、BFS などの特定のファイルシステムでのみ機能します。 このソリューションは高速であるため、システム (トラッカーおよびデスクバー) によって表示されるアイコンは、この拡張属性から読み取られます。 一部の場所 (通常の「バージョン情報」ウィンドウなど、速度が重要ではない場所) では、システムはファイル内のリソースからアイコンを直接受け取ります。 しかし、これで終わりではありません。 Mac では、ユーザーはアプリケーション、フォルダー、ドキュメントのアイコンを自分のアイコンに置き換えることができることに注意してください。Mac では、たとえば次のような「重要な」ことを実行できるためです。 新しい Slack アイコンを以前のアイコンに置き換える。 Haiku では、(ファイル内の) リソースはアプリケーションに付属する元のアイコン、(BFS ファイルシステム内の) 属性はユーザーが自由に変更できるようにするものと考えてください (ただし、ヒントとして、アイコンの上にカスタム アイコンを挿入することはオプションです)。デフォルトではまだ実装されていません)。

ファイルシステム属性の確認

ととも​​に resaddr ファイルシステム属性を確認および設定することができます。

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]

Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

これは本質的に、(信頼性の高い) リソースと (高速な) ファイル システム属性の間の相互変換を行う「接着剤」です。 また、システムがリソースの取得を前提としてコピーを自動的に行うので、これ以上心配する必要はありません。

hpkg パッケージの魔法

現在 (ほとんどの場合) パッケージは、Haiku でプログラムを取得するために使用されます。 .hpkg。 単純な名前に騙されないでください。.hpkg 形式は、これまでに見つけた他の同様の名前の形式とは動作が大きく異なり、真のスーパーパワーを持っています。

従来のパッケージ形式では、あるもの (パッケージ) をダウンロードすると、別のもの (パッケージ内のファイル) がシステムにインストールされるという事実のために、私は長い間腹を立てていました。 従来の方法でパッケージをインストールする場合、ファイルの管理 (削除など) は非常に困難です。 そしてすべてはパッケージの内容のためです ファイルシステム全体に分散しているこれには、通常のユーザーが書き込みアクセス権を持たない可能性のある場所も含まれます。 これにより、プログラムのクラス全体が生成されます - パッケージマネージャー。 しかし、すでにインストールされているソフトウェアを、たとえば別のマシン、リムーバブル ディスク、またはファイル サーバーに転送することは、不可能ではないにしても、さらに困難になります。 一般的な Linux ベースのシステムでは、数十万から数百万の個別のファイルが簡単に存在する可能性があります。 言うまでもなく、これは、たとえばシステムの初期インストール時、通常のパッケージのインストール、更新、削除時、ブート ボリューム (ルート パーティション) を別のメディアにコピーするときなど、脆弱で遅いものです。

私は、エンド ユーザー アプリケーションの部分的な支援となる AppImage プロジェクトに取り組んでいます。 これは、アプリケーションとそのすべての依存関係を XNUMX つのファイル システム イメージに収集し、アプリケーションの起動時にマウントされるソフトウェア配布形式です。 同じ ImageMagick が突然、単なる人間によってファイル マネージャーで管理される単一のファイルに変わるため、物事が大幅に簡素化されます。 プロジェクト名に反映されているように、提案された方法はソフトウェアに対してのみ機能します。また、Linux ソフトウェア ベンダーが常に私を指摘しているため、独自の一連のバグもあります。

俳句の話に戻りましょう。 従来のパッケージング システムとイメージベースのソフトウェア配信の間の適切なバランスを見つけましたか? 彼女の荷物 .hpkg 実際に圧縮されたファイル システム イメージ。 システムが起動すると、カーネルは、次のようなカーネル メッセージを使用して、インストールされているアクティブなパッケージをすべてマウントします。

KERN: package_daemon [16042853:   924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"

クールですね？ 待ってください、それはさらに悪化するでしょう！

非常に特別なパッケージがあります:

KERN: package_daemon [16040020:   924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

これには、カーネルを含む非常に最小限のオペレーティング システムが含まれています。 信じられないかもしれませんが、カーネル自体もブート ボリューム (ルート パーティション) から抽出されるのではなく、パッケージから適切な場所にきちんとロードされます。 .hpkg。 おお！ 先ほども述べましたが、私にとって、Haiku の全体的な洗練さと一貫性の一部は、カーネルとその基盤となるユーザースペースから、パッケージ管理とデスクトップ インフラストラクチャに至るまで、システム全体が XNUMX つのチームによって共同開発されているという事実から来ています。 Linux 上でこのようなものを実行するには、どれだけの異なるグループやチームが必要になるかを想像してみてください。 [私は PuppyLinux プロジェクトを想像しています。 翻訳者]。 次に、このアプローチがディストリビューションに実装されるまでにどれくらい時間がかかるかを想像してください。 彼らはこう言います。「単純なタスクを複数の実行者に分割すると、非常に複雑になり、解決できなくなります。」 この場合、俳句が私の目を開かせてくれました。 これはまさに今 Linux で起こっていることだと思います (この場合の Linux は、Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu スタックの総称です)。

hpkgを使用したシステムのロールバック

更新が成功したのに、何かが正常に動作していないことが判明するという状況はどのくらいの頻度で発生しますか? 通常のパッケージ マネージャーを使用している場合、システムの状態を新しいパッケージをインストールする前の時点 (たとえば、何か問題が発生したとき) に戻すのは困難です。 一部のシステムでは、ファイルシステムのスナップショットの形式で回避策を提供していますが、これは面倒であり、すべてのシステムに適用できるわけではありません。 Haiku では、これはパッケージで解決されます .hpkg。 システム内のパッケージが変更されるたびに、古いパッケージは削除されず、システム内の次のようなサブディレクトリに保存されます。 /Haiku/system/packages/administrative/state-<...>/ 常に。 保留中の操作はデータをサブディレクトリに保存します /Haiku/system/packages/administrative/transaction-<...>/.

コンテント /Haiku/system/packages/administrative。 「state ...」ディレクトリには、アクティブなパッケージの名前を含むテキスト ファイル、「transaction ...」 (パッケージ自体) が含まれています。

「古いアクティブ状態」、つまりリスト .hpkg ファイルマネージャーでの各操作後にテキストファイルに変更が書き込まれる前にアクティブなパッケージ /Haiku/system/packages/administrative/state-<...>/activated-packages。 同様に、新しい「アクティブ状態」がテキスト ファイルに書き込まれます。 /Haiku/system/packages/administrative/activated-packages.

ディレクトリ /Haiku/system/packages/administrative/state-<...>/ この状態のアクティブなパッケージのリストを含むテキスト ファイルのみが含まれます (パッケージを削除せずにインストールする場合)。パッケージが削除または更新された場合、状態ディレクトリには古いバージョンのパッケージが含まれます。

システムが起動すると、パッケージのリストに基づいて、パッケージをアクティブ化 (マウント) するかどうかが決定されます。 とても簡単です！ ダウンロード中に問題が発生した場合は、ダウンロード マネージャーに別の古いリストを使用するように指示できます。 問題が解決しました！

Haiku ブートローダー。 各エントリ ポイントには、対応する「アクティブ状態」が表示されます。

わかりやすい名前が付いた「アクティブな状態」リストとしてプレーン テキスト ファイルを使用するアプローチが気に入っています .hpkg。 これは、人間のためではなく機械のために作られたものとはまったく対照的です。 束 ファイル システム内の OSTree または Flatpak (Microsoft GUID と同じレベル) から。

各時点のアクティブなパッケージのリスト

設定データ

どうやらカタログ /Haiku/system/packages/administrative/writable-files パッケージの構成ファイルが含まれていますが、書き込み可能です。 結局のところ、あなたが覚えているように、 .hpkg 読み取り専用でマウントされます。 したがって、これらのファイルは書き込む前にパッケージからコピーする必要があります。 意味があります。

.hpkg システムの GUI 統合

これらの光沢のあるパッケージがどのように機能するかを見てみましょう .hpkg ユーザーの作業環境 (UX) への統合に対応します。 結局のところ、俳句は個人的に使用するものです。 個人的に、私はユーザー エクスペリエンスをパッケージと比較することで、基準を高く設定しました。 .app Macintosh でも同じエクスペリエンスが得られます .hpkg。 この状況を Linux デスクトップ環境と比較することさえしません。他の環境と比較するとまったくひどいものだからです。

次のようなシナリオが思い浮かびます。

• パッケージの中身を見たい .hpkg
• パッケージをインストールしたい
• パッケージを削除したい
• パッケージの一部としてシステムに入ったものを削除したい
• パッケージの一部としてシステムに組み込まれたものをコピーしたい
• すべての Haiku インストールの一部ではないパッケージの依存関係をすべてダウンロードしたいと考えています (たとえば、インターネットにアクセスできない物理的に隔離されたマシンがあります)。
• パッケージ (その一部) を、ブート ボリューム (ルート パーティション) とは別の別の場所に個別に移動したいと考えています (たとえば、十分なスペースがないため)。

これで、私の日常業務の主なケースのほとんどがカバーされるはずです。 さて、始めましょう。

パッケージ内容の確認

Macの場合 パッケージを右クリックするだけでパッケージが開き、Finder で内容が表示されます。 それは実際には、偽装された単なるディレクトリです。 (パッケージがあることは知っています .pkg これはアプリケーションではないシステムの一部ですが、通常のユーザーはほとんどの場合それらを操作しません)。

俳句について パッケージを右クリックし、[コンテンツ] をクリックして中身を確認します。 ただし、これは単なるファイルのリストであり、ダブルクリックして開く機能はありません。
パッケージを（一時的に）マウントする方法があればもっと良いでしょう .hpkg ファイルマネージャーを通じて表示できるため、ユーザーは実装の詳細について心配する必要がなくなります。 （ちなみに開けることもできます） .hpkg パッケージに入れる Expander、他のアーカイブと同様に解凍できます）。

HaikuDepot のインターフェイスでは、パッケージ ファイルのリストを表示できますが、README.md をダブルクリックするなどして内容を表示する方法はありません。

このカテゴリでは Mac が勝ちますが、HaikuDepot に適切な機能を追加するのは大したことではありません。

GUIを介したパッケージのインストール

Macの場合、ほとんどのディスクイメージ .dmg パッケージを含む .app。 ダブルクリックしてディスク イメージを開き、パッケージをドラッグするなどしてコピーします。 /Applications ファインダーで。 私にとっては当たり前のことですが、初心者の中にはこれを使いこなせない人もいるそうです。 デフォルトでは、Apple はシステム全体のディレクトリを「提案」します。 /Applications (NeXT では、個別だけでなくネットワークにも接続されていました) ですが、アプリケーションをファイル サーバーまたはサブディレクトリに簡単に配置できます。 $HOME/Applicationsそんなに好きなら。

俳句について、パッケージをダブルクリックし、[インストール] をクリックするだけです。これは非常に簡単です。 パッケージに HaikuPorts で利用可能な依存関係があるが、まだインストールされていない場合はどうなるのか疑問に思っています。 Linux では、この状況で何をすべきか実際にはわかりませんが、解決策は明らかです。依存関係をダウンロードしてインストールする必要があるかどうかをユーザーに尋ねます。 まさに俳句がやっていることです。

「sanity」パッケージを手動でダウンロードしてクリックすると、パッケージ マネージャーはその依存関係をどこから取得すればよいかを認識します (リポジトリがすでにシステム上にあると仮定します)。 すべての Linux ディストリビューションがこれを実行できるわけではありません。

もう XNUMX つの方法は、ファイル マネージャーを使用することです。ドラッグ アンド ドロップするだけです。 .hpkg パッケージまたは中に /Haiku/system/packages (システム全体のインストールの場合、デフォルト)、または /Haiku/home/config/packages (個別の設定の場合。ダブルクリックでは利用できません。この場所の「構成」という単語にはまだイライラしていますが、この場合、私にとってこれは「設定」の同義語です)。 そして、複数ユーザーの概念は、Haiku ではまだ利用できません (おそらくそれが非常に単純な理由です。私にはわかりませんが、おそらくマルチユーザー機能は、デスクトップ環境では物事を不必要に複雑にするでしょう)。

このカテゴリでは、アプリケーションだけでなくシステム プログラムとも連携できる Haiku が勝ちます。

GUI からのパッケージの削除

Macの場合、アプリケーションのアイコンをゴミ箱にドラッグするだけです。 簡単に！

俳句についてまず、パッケージがシステム内のどこにあるかを見つける必要があります。パッケージが正しい場所にインストールされることはめったにありません (システムがすべてを実行します)。 通常、探す必要があります /Haiku/system/packages (システム全体のデフォルトのインストールの場合)、または /Haiku/home/config/packages (「config」という名前は間違っていると言いましたか?) その後、アプリケーションをゴミ箱にドラッグするだけで完了です。
簡単に！ しかし、私はそうは言いません。 実際に何が起こっているかは次のとおりです。

アプリをゴミ箱にドラッグすると、次のようになります。 /Haiku/system/packages

QtQuickApp 上の昨日の「Hello world」アプリをゴミ箱に移動してみました。 システムディレクトリを移動しようとしたわけではありませんが、 すべてのパッケージはシステム ディレクトリにインストールされているため、パッケージを削除することはできません .hpkg 変わらずに 「その内容」。 普通のユーザーなら怖くて、デフォルトで割り当てられている「キャンセル」ボタンを押すでしょう。

説明します 氏。 よちよちスプラッシュ:

この投稿は 10 年以上前のものです。 おそらく、パッケージ自体が移動された場合にのみ警告が表示されるように設定する必要があります。 一般のユーザーはこれを行う必要はありません。

そうですね、HaikuDepot を使ったほうがいいでしょうか? パッケージをダブルクリックします /Haiku/system/packages, 「アンインストール」ボタンが表示されるのを待ちます。 いいえ、「インストール」（のみ）があります。 アンインストールしてください、どこにいますか?

楽しみのために、すでにインストールされているパッケージで「インストール」をクリックすると何が起こるか試してみました。 次のようになります。

これは、既にインストールされているパッケージをインストールしようとすると発生します。

次に表示されます:

前のウィンドウで「変更を適用」をクリックすると、次のようになります

これはソフトウェア エラーだと思いますが、アプリケーションへのリンクはすでに存在しています。 [著者はリンクを提供していませんでした。 翻訳者]

クイックフィックス: パッケージが既に存在する場合は、「アンインストール」ボタンを追加します。 /Haiku/system/packages、または /Haiku/home/config/packages.

HaikuDepot にインストールされているパッケージのリストを表示すると、リストに自分のパッケージが表示され、削除できます。

この部門では Mac が優勝します。 しかし、適切に設定すれば、Haiku でのユーザー エクスペリエンスが Mac よりも向上することは想像できます。 (開発者の XNUMX 人は次のように評価しました。「C++ を少し知っていれば、指定された機能を HaikuDepot に追加するのに XNUMX 時間もかからない」。ボランティアの方はいらっしゃいますか?)

パッケージから何かを取り出す

パッケージではなくアプリ自体をアンインストールしてみましょう .hpkg、そこからそれが現れました（「単なる人間」に違いがあるとは思えません）。

Macの場合、ユーザーは実際に通常どおりファイルを操作します .dmgアプリケーションパッケージの出所 .app。 通常は画像 .dmg ダウンロード ディレクトリに蓄積され、パッケージはユーザーによってコピーされます。 /Applications。 多くのユーザー自身が自分が何をしているのか理解していないと考えられており、この仮説は元 Apple 従業員によって確認されています。 (Mac で気に入らない点の XNUMX つです。たとえば、AppImage の場合、アプリとそれが入っていたパッケージの間に違いはありません。アイコンをゴミ箱にドラッグするだけです。それだけです。簡単です!)

俳句について、の間にも分かれがあります。 apps/ и packages/, したがって、これでユーザーにとってわかりやすくなったとは思えません。 しかし、アプリケーションをドラッグするとどうなるでしょうか。 apps/ カートに追加：

ファイルから取得したアプリケーションを削除しようとすると、次のことが起こります。 .hpkg

これは技術的には正しいのですが (結局のところ、そもそもアプリケーションは読み取り専用のファイル システムでホストされているのです)、ユーザーにとってはあまり役に立ちません。

クイックフィックス: 代わりに GUI 経由で削除を提案する .hpkg

楽しみのために、Alt + D を押してアプリケーションを複製してみました。 「読み取り専用ボリューム上のオブジェクトを移動またはコピーできません。」というメッセージが表示されました。 そしてすべての理由は /system （そのほか /system/packages и /system/settings) は packagefs のマウント ポイントです (出力にどのように表示されるかを思い出してください) df?)。 残念ながら、コマンドの出力は mount (以前の記事の XNUMX つで述べたように) 状況は明確ではありませんが、 mountvolume 探しているものが表示されません（どうやらループ経由でパッケージがマウントされています） .hpkg は「ボリューム」とみなされません)、また、代替コマンドを忘れてしまいました。

このカテゴリーでは、AppImage を除いて誰も優勝しませんでした (ただし、これは完全に正直に言うと、偏った意見です)。 ただし、調整後は、Haiku でのユーザー エクスペリエンスが Mac よりも向上することは想像できます。

注: 「パーティション」に関連する「ボリューム」が何であるかを把握する必要があります。 これはおそらく、「フォルダ」と「ディレクトリ」の関係に似ています。ほとんどのディレクトリはファイル マネージャではフォルダとして表示されますが、すべてがフォルダとして表示されるわけではありません（たとえば、パッケージがファイルとして扱われる）。 このようなことは私を正式にオタクにしますか？

パッケージの内容を別のシステムにコピーする

Macの場合、愚かにもパッケージを引っ張る .app、依存関係はパッケージ内にあるため、一緒に移動します。

俳句について, アプリケーションをドラッグしても、依存関係がまったく処理されません。

クイックフィックス: 代わりに、依存関係がある場合は、「`.hpkg」パッケージ全体と依存関係をドラッグすることをお勧めします。

このカテゴリでは、明らかに Mac が勝ちます。 少なくとも、彼らのパラダイムを愛する私にとっては。 俳句は真似すべきだ .hpkg アプリケーションの代わりですが、システムはこれを提供しません...

すべての依存関係を含むパッケージをダウンロードする

すべてのマシンが常にオンラインであるわけではありません。 それどころか、一部のマシン (そう、今の Windows、Mac、Linux) はそれを忘れてしまいます。 私にとって重要なのは、たとえば、インターネット カフェに行って、ソフトウェアをリムーバブル メディアにダウンロードし、そのメディアを自宅のコンピュータに挿入して、すべてが正常に機能することを確認できることです [リスクを負う人、これを Windows で実行してください... - 約。 翻訳者]。

その結果、通常よりも少し頻繁に、Windows と Linux で満たされていない依存関係が発生することになります。

Macの場合 通常、これは XNUMX つのファイルなので、ダウンロードするだけで済みます .dmg。 ほとんどの場合、デフォルトで MacOS 自体によって提供される依存関係以外に依存関係はありません。 例外は、Java などの適切なランタイム環境を必要とする複雑なアプリケーションです。

俳句について パッケージをダウンロードする .hpkg たとえば、同じ Java アプリケーションの場合、ターゲット マシンに Java が存在する場合と存在しない場合があるため、これでは不十分な場合があります。 特定のパッケージのすべての依存関係をダウンロードする方法はありますか .hpkgHaiku にデフォルトでインストールされているため、すべての Haiku システムにインストールする必要があるもの以外はどうですか?

このカテゴリでは、僅差で Mac が勝利します。

氏からのコメント。 よちよちスプラッシュ:

アプリケーションのすべての依存関係をパッケージのセットとして収集するプログラムを作成するには .hpkg Haiku の内部に詳しい人であれば、15 分程度で十分です。 本当に必要がある場合、これのサポートを追加するのはそれほど難しいことではありません。 しかし、私にとってこれは珍しいことです。

このシリーズの次の記事まで息を止めてみましょう。

パッケージを別の場所に移動する

前にも書きましたが、荷物を置きたいのです .hpkg (またはその一部) を、ブート ボリューム (ルート パーティション) 上の通常の配置とは別の特別な場所にコピーします。 通常の (それほど理論的ではない) ケースでは、その理由は、(内蔵) ドライブがどんなに大きくても、常に空き容量が不足していることです。 そして、私は通常、アプリケーションが存在する外部ドライブまたはネットワーク共有をマッピングします。

Macの場合 パッケージを移動するだけです .app Finder のリムーバブル ドライブまたはネットワーク ディレクトリにコピーするだけです。 通常ブート ボリュームから行うのと同じように、ダブルクリックしてアプリを開くことができます。 ただ！

俳句について、言われたように、これは私の体を動かすことで達成できます。 .hpkg パッケージをリムーバブル ドライブまたはネットワーク ディレクトリに保存しますが、それらをシステムにマウントするには、コンソールで文書化されていないコマンドを使用する必要があります。 GUIだけではやり方が分かりません。

この部門では Mac が優勝します。

氏によれば、 よちよちスプラッシュ:

これは通常の使用に基づいた最適化です。 複数のユーザーからのご要望があれば、実装させていただきます。 いずれにしても、サードパーティによる実装の可能性があります。

これについては次の記事で説明します。

ネットワーク ディレクトリについて言えば、ローカル コンピュータにコピーしたり、ローカル ネットワークから直接実行したりできる、シンプルで検出可能なネットワーク全体のアプリケーション (Zeroconf など) があれば素晴らしいでしょう (LAN 関係者はそうでしょう)。 もちろん、開発者には次の方法でオプトアウトするオプションがあります。 app_flags.

hpkg システムと GUI の統合に関する最終レポート

これは主に、統合が比較的目新しかったためだと思います。 .hpkg GUI にはまだ改善の余地がたくさんあります。 とにかく、UX の点で改善できる点がいくつかあります...

もう XNUMX つ: カーネル デバッグ ランド

カーネルパニック中にコマンドを入力できると便利です。たとえば、 syslog | grep usb。 Haiku では、Kernel Debug Land のおかげでそれが可能です。 カーネル パニックに陥ることなく、すべてが正常に動作している場合、この魔法が実際に動作していることをどのように確認できるでしょうか? Alt+PrintScn+D (デバッグニーモニック) を押すことで簡単に実行できます。 すぐに思い出します プログラマーのキーこれにより、元の Macintosh 開発者はデバッガに入ることができました (もちろん、デバッガがインストールされていた場合)。

まとめ

Haiku システムの洗練さは、作業環境に明確に焦点を当てた XNUMX つの小さなチームによって作業が行われ、システムのすべての層にアクセスできるという事実から来ていることに気づき始めています。
Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu の世界とははっきりと対照的です。そこでは、抽象化が抽象化の上に座って松葉杖を駆動するほど、すべてが小さな部分に分割されています。
システムの仕組みについても理解できました .hpkg 従来のパッケージ マネージャー、Snappy、Flatpak、AppImage、さらには btrfs のベスト プラクティスを組み合わせ、Mac の「そのまま使える」アプローチと組み合わせます。

頭の中で何かが「切り替わった」かのように、システムがどのように機能するかを理解しました。 .hpkg 彼女を見るだけで、転がり去る方法を知っています。 しかし、これは私ではなく、システムの美しさとシンプルさです。 ここには初代 Mac の精神がたくさん詰まっています。

はい、ブラウザでのブラウジングはぎくしゃくしてカタツムリのように動作する可能性があり、アプリケーションが不足している可能性があります (Gtk や Electron はありません - 開発者は、これらは洗練されたものとは相性が悪いと結論付けています)、ビデオと 3D アクセラレーションは完全に欠如している可能性がありますが、それでも私はこのシステムが好きです。 結局のところ、これらのことは修正することができ、遅かれ早かれ現れるでしょう。 それは時間の問題であり、おそらく少し目が赤くなるだけです。

力にはなれませんが、これから始まると思います。 デスクトップ上の俳句の年.

ランダムな問題

おそらくアプリケーションがすでにあるのでしょうか、それともそれらを開いたほうがよいでしょうか?

• BeScreenCapture は Peek のように GIF にエクスポートできるはずです。 これは、Haiku ですでに利用可能な ffmpeg を使用して行うことができます。 リクエスト.
• スクリーンショット ツールはモーダル ウィンドウのスクリーンショットを取得できず、代わりに画面全体をキャプチャします。
• WonderBrush のトリミング ツールを使用してスクリーンショットをトリミングし、結果をファイルに保存することはできません。
• 俳句のハンドカーソルはあまり好きではありませんが、どこか懐かしい温かみのある雰囲気があると思います。 これは、Krita でトリミング ツールを使用する場合、不正確なトリミングになるため、特に迷惑です (この記事のモーダル ダイアログのスクリーンショットを参照してください)。 十字カーソルがあれば便利です。 リクエスト.

あなたも試してみてください！ 結局のところ、Haiku プロジェクトは、DVD または USB から起動するためのイメージを提供します。 日々。 インストールするには、イメージをダウンロードし、次のコマンドを使用して USB フラッシュ ドライブに書き込むだけです。 エッチャー

質問がありますか? ロシア語圏へご招待します 電報チャンネル.

エラーの概要: C および C++ で自分の足を撃つ方法。 Haiku OS レシピ集

から 作者 翻訳: これは俳句シリーズの XNUMX 番目の記事です。

記事一覧： 最初の 2番目 Третья 4番目 第5

出所： habr.com