Toolbox: デスクトップファイルの統合

作成日 2020年04月21日  ·  18コメント  ·  ソース: containers/toolbox

GUIアプリ(VS Code、GNOME Builderなど)をインストールすると、/ usr / share / applicationsにデスクトップファイルが作成されます。 ただし、ツールボックスには分離されたシステム(homedirを除く)があり、バインドされません。
次のように、そこからデスクトップファイルを作成するオプションがある場合:
$ toolbox desktop code.desktopは次のことを行います。

  1. /usr/share/applications/code.desktopを.local / share / applications /toolbox_code.desktopにコピーします
  2. すべての実行可能参照(/ usr / bin / codeまたはcode)をconainersに変更します(/ usr / bin / code-> toolbox run / usr / bin / code et cetera)
  3. アイコンをローカルアイコンストレージにコピーする

また、削除するオプションを追加します。
$ toolbox desktop code.desktop -r
〜/ .local / share / applications /toolbox_code.desktopとアイコンを削除します

1. Feature request 5. Good First Issue 5. Help Wanted

最も参考になるコメント

私はそれを目指しています!

全てのコメント18件

こんにちは@ oksoft-git! これは面白そうだ。 私はこれに似たものを提供することを考えていました。 この機能を使用してPRを作成しますか(ただし、ShellではなくGoで新しいバージョンのToolboxを使用しますか?

@debarshiray 、どう思いますか?

私はそれを目指しています!

この機能は、silverblueユーザーに大きなメリットをもたらし、コンテナーからアプリケーションを簡単に使用できるようになります。

基本的なバイナリ統合を含めて、基本的なコマンドラッパーを基本システムにエクスポートできるようにすることは可能ですか、それともプロジェクトの範囲外ですか?

コマンドラッパーとして、たとえばnanoの場合はこのようなラッパーを意味します(一部のプログラムではこれよりも複雑な場合があります)

!/bin/bash
toolbox nano "$@"

(flatpakはこのようなことをします、それをさらに調べることができます)

こんにちは@sandorex ! あなたが話している機能はすでにここで追跡されています:#145。 これは、更新されたツールボックスを公開した後の優先事項の1つです。 これらの2つの機能は似ていますが、それらの解決策は大きく異なります。

Toolboxにアプリ用の.desktopファイルを作成/編集する機能を与えることが本当に道であるかどうか疑問に思っています。 Toolboxは、既存の.desktopファイルの場所を認識し、適切な行を見つけて更新し、デスクトップ(GNOME Shellを使用しているわけではありません)がファイルを見つけて使用する場所にファイルを移動/コピーする必要があります。 これは、あまり役に立たない不必要に大きなロジックの塊のように私には思えます。

代わりに、既存の.desktopファイルを更新する方法の説明が記載されたドキュメントのセクションの方が私にはよく聞こえます。

複雑さについて間違っている場合は、間違っていることを証明してください。

私は間違っているかもしれませんが、デスクトップファイルは~/.local/share/applications再帰的に検索されるため、ツールボックスからデスクトップファイルのみを含むディレクトリ(コンテナごと)を削除し、コンテナに存在しないデスクトップファイルを削除しますが、変更は実際にはできません簡略化する

第二のアプローチは、別のアプリケーションにこの責任(与えるだろうtoolbox-desktop-integration (、スマートになり、そのフォルダにそれらを置くホストにもたらすにデスクトップファイルの選択を可能にする)のような~/.local/share/applications/_toolbox_XXX XXXはコンテナ名です)

あなたの意見に興味があります@HarryMichal

ほぼ完了しましたが、デスクトップファイルからアイコンパスを抽出してホストにコピーすることができません。

_edit_:専用のツールを作成する方が良いでしょう。 再現します。

まあ、私はそれを持っています。 github.com/ondra05/toolbox-desktop

@ ondra05お疲れ様でした

私が個人的に改善したことが1つあります(ただし、必須ではありません)。それは、 catを使用してコンテナーからファイルを読み取ることです。正常に動作しますが、ちょっとハックで、 podman画像を共有します。 toolboxを使用すると、 podman cpを使用して、コンテナーとホスト間でファイルをコピーできます。

私はこのPythonスクリプトでこのアイデアをいじっています。 現在、デスクトップファイル、アイコン、mime、metainfoをインストールしています。 アンインストール機能はまだ追加していませんが、それほど難しくはないようです。

悲しいことに、適切なアプリを実行する時間がありません。UIを作成しましたが、GTKはお尻が痛いだけで、いつかCLIのみのアプリを実行する可能性があります(うまくいけば)

悲しいことに、適切なアプリを実行する時間がありません

このためのGUIはやり過ぎだと思います。 これは、 --removeおよび--listフラグを使用して、 toolbox exportの方向のコマンドで処理する必要があります。

調べてみます。 たとえば、 toolbox run export.py ARGSと同様の方法で、ツールボックス内にこのpythonスクリプトを呼び出すtoolbox export APPコマンドを追加するだけでよいのではないかと思います。 外出先で行う方が明らかに優れていますが、これにはツールボックスの/usrから$XDG_DATA_DIRへのファイルのコピーのみが含まれ、スクリプトを使用する方が簡単な場合があります。 この可能性のメンテナが何なのかわかりません。

このような拡張機能では多くのことを考慮に入れる必要があることに注意してください。たとえば、アイコンの処理の問題は重要です。

これは、Freenodeの#silverblueからのこのIRC会話を含む、runコマンドの追加に関する議論に似てい

From #silverblue on Freenode:

15:56 <rishi> otaylor: alexlarsson: Hey! Do you have any thoughts on            
      https://github.com/debarshiray/toolbox/pull/76 ?
15:57 <rishi> In short, people want to be able to do "toolbox run emacs".
15:57 <rishi> And I am worried about encroaching on Flatpak territory.
15:58 <alexlarsson> I don't think its a huge problem.
15:58 <otaylor> rishi: I suspect we need such functionality if we want the      
      toolbox to be a serious tool that people rely on
15:58 <alexlarsson> No 2 tools will be 100% non-overlapping
15:59 <alexlarsson> and i can imagine using this in non-flatpak like way
15:59 <alexlarsson> toolbox run some-service
15:59 <otaylor> rishi: I'd be more worried about adding, say, menu item         
      management so that it looks like 'toolbox run emacs' is a real app
16:00 <alexlarsson> I mean, some people use flatpak for cli stuff
16:00 <rishi> otaylor: alexlarsson: Okay!
16:00 <alexlarsson> which is not quite the point
16:00 <alexlarsson> Still, it works
16:01 <alexlarsson> The main thing is that the design decisions that drive      
      toolbox and flatpak are driven by a particular usecase
16:01 <alexlarsson> Not that they can't be used other ways
16:03 <rishi> Yeah, toolbox is very clearly: "use jhbuild on Silverblue".
16:04 <rishi> walters would say "separate development prefix", but that's       
      about it, I think.

コンテナ内にインストールされているアプリケーションの.desktopファイルにtoolbox run emacsを追加することはすでに可能です。 実際に.desktopファイルを解析して作成するコマンドをわかりません。

@debarshirayデスクトップファイル、icondata、メタデータをコピーするPythonスクリプトについてどう思いますか? 私はすでにそれを作りました、そしてそれはうまく働いています。

それは間違いなくそれについて行く一つの方法です。 しかし、私は今それをToolboxに含めることを躊躇しています。

私はこの問題に取り組むことに興味があります!

..。
誰もがGNOMEShellを使用しているわけではありません
..。
複雑さについて間違っている場合は、間違っていることを証明してください。

@HarryMichalあなたの心配は不要だと思います。
現在、.desktopファイルとアイコンファイルのテーマは、デスクトップに依存しないように設計されており、 XDG仕様の対象となります。
https://specifications.freedesktop.org/
https://specifications.freedesktop.org/desktop-entry-spec/latest/index.html
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

すべての人に:
必要な機能をDNFプラグインとして設計できますか?

PS:Flatpakはすでにアプリを公開しているので、必要に応じてコードを借りることができます。

アンインストール機能はまだ追加していませんが、それほど難しくはないようです。

ありがとう@ A6GibKm 、してください! :)

このページは役に立ちましたか?
0 / 5 - 0 評価