GUIアプリ(VS Code、GNOME Builderなど)をインストールすると、/ usr / share / applicationsにデスクトップファイルが作成されます。 ただし、ツールボックスには分離されたシステム(homedirを除く)があり、バインドされません。
次のように、そこからデスクトップファイルを作成するオプションがある場合:
$ toolbox desktop code.desktop
は次のことを行います。
また、削除するオプションを追加します。
$ toolbox desktop code.desktop -r
〜/ .local / share / applications /toolbox_code.desktopとアイコンを削除します
こんにちは@ 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 、してください! :)
最も参考になるコメント
私はそれを目指しています!