Toolbox: Integration von Desktop-Dateien

Hallo @oksoft-git! Das sieht interessant aus. Ich hatte überlegt, etwas Ähnliches anzubieten. Möchten Sie mit dieser Funktion eine PR erstellen (aber nicht in Shell, sondern in Go für die neue Version von Toolbox ?

@debarshiray , was denkst du?

Ich gehe dafür!

Diese Funktion würde Silverblue-Benutzern sehr zugute kommen, da Sie dann problemlos Anwendungen aus dem Container verwenden können

Wäre es möglich, eine grundlegende Binärintegration einzubeziehen, um grundlegende Befehlswrapper in das Basissystem zu exportieren, oder ist dies nicht im Rahmen des Projekts?

Als Befehls-Wrapper meine ich Wrapper wie diesen für Nano zum Beispiel (er kann für einige Programme komplexer sein als dieser)

!/bin/bash
toolbox nano "$@"

(flatpak macht so etwas, könnte es weiter untersuchen)

Hallo @sandorex ! Das Feature, von dem Sie sprechen, wird hier bereits verfolgt: #145. Dies ist eine der Prioritäten nach der Einführung der aktualisierten Toolbox. Obwohl diese beiden Funktionen ähnlich sind, ist die Lösung für sie sehr unterschiedlich.

Ich frage mich jetzt, ob es wirklich der richtige Weg ist, Toolbox die Möglichkeit zu geben, .desktop-Dateien für Apps zu erstellen/zu bearbeiten. Dazu müsste Toolbox wissen, wo die vorhandene .desktop-Datei zu finden ist, die richtigen Zeilen finden, sie aktualisieren und die Datei an einen Ort verschieben/kopieren, an dem der Desktop (nicht jeder verwendet die GNOME-Shell) sie findet und verwendet. Dies scheint mir ein unnötig großer Teil der Logik zu sein, der nicht viel nützen würde.

Stattdessen klingt der Abschnitt in der Dokumentation mit Anweisungen zum Aktualisieren einer vorhandenen .desktop-Datei für mich besser.

Wenn ich mit der Komplexität falsch liege, beweisen Sie mir bitte, dass ich falsch lag.

Ich kann mich irren, aber Desktop-Dateien werden rekursiv in ~/.local/share/applications durchsucht, also ein Verzeichnis, das nur Desktop-Dateien aus der Toolbox (pro Container) enthält, und dann einfach die Desktop-Dateien entfernen, die nicht im Container vorhanden sind, aber die Änderung kann ich nicht wirklich vereinfachen

Der zweite Ansatz wäre, diese Verantwortung einer anderen Anwendung ( toolbox-desktop-integration ) zu übertragen, die eine Auswahl von Desktop-Dateien ermöglicht, die zum Host gebracht werden sollen (sie in ihre Ordner zu legen wäre klug, wie ~/.local/share/applications/_toolbox_XXX wo XXX ist der Containername)

Interessiert an deiner Meinung @HarryMichal

https://github.com/ondra05/toolbox

Es ist fast fertig, aber ich kann den Symbolpfad nicht aus der Desktop-Datei extrahieren, um ihn auf den Host zu kopieren.

_edit_: Es ist besser, ein spezielles Tool dafür zu erstellen. Ich werde es neu erstellen.

Nun, ich habe es. github.com/ondra05/toolbox-desktop

@ondra05 Tolle Arbeit!

Es gibt eine Sache, die ich persönlich verbessern würde (es ist aber nicht notwendig) und das ist die Verwendung von cat zum Lesen der Datei aus dem Container. Es wird gut funktionieren, aber es ist irgendwie hackig, weil podman Bilder teilt mit toolbox Sie mit podman cp Dateien zwischen Container und Host kopieren

Ich habe mit dieser Idee in diesem Python-Skript gespielt. Derzeit installiert es Desktop-Dateien, Symbole, Pantomime und Metainfo. Ich muss noch eine Deinstallationsfunktion hinzufügen, scheint aber nicht zu schwer zu sein.

Ich habe leider keine Zeit, eine richtige App zu erstellen, ich habe die Benutzeroberfläche erstellt, aber GTK ist nur eine Nervensäge, ich werde wahrscheinlich eines Tages nur eine CLI-App machen (hoffentlich)

Ich habe leider keine Zeit für eine richtige App

Ich denke, dass eine GUI dafür übertrieben ist. Imho sollte dies mit Befehlen in Richtung toolbox export mit Flags wie --remove und --list gehandhabt werden.

Ich werde versuchen, es zu untersuchen. Ich frage mich, ob es möglich ist, einfach einen toolbox export APP Befehl hinzuzufügen, der beispielsweise dieses Python-Skript in der Toolbox auf ähnliche Weise wie toolbox run export.py ARGS aufruft. Es ist zwar eindeutig besser, dies in go zu tun, aber dies erfordert nur das Kopieren von Dateien von /usr Toolbox nach $XDG_DATA_DIR und es könnte einfacher sein, ein Skript dafür zu verwenden. Ich weiß nicht, was der Betreuer von dieser Möglichkeit hält.

Beachten Sie, dass eine solche Erweiterung viele Dinge berücksichtigen müsste, zum Beispiel ist das Problem der Handhabung von Symbolen nicht trivial.

Dies ähnelt der Diskussion um das Hinzufügen des Befehls run , einschließlich dieser IRC-Konversation von #silverblue auf Freenode:

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.

Es ist bereits möglich, toolbox run emacs in die .desktop- Datei für die im Container installierte Anwendung hinzuzufügen. Einen Befehl zu haben, der tatsächlich .desktop- Dateien analysiert und erstellt, ist ein weiterer Schritt in die gleiche Richtung, und ich bin mir nicht sicher, ob das ein Schritt zu weit ist.

@debarshiray was halten Sie von einem Python-Skript, das Desktop-Dateien, Symboldaten und Metadaten kopiert? Ich habe schon eine gemacht und sie funktioniert einwandfrei.

Es ist definitiv ein Weg, dies zu tun. Ich zögere jedoch, es jetzt in Toolbox aufzunehmen.

Ich bin daran interessiert, an diesem Thema zu arbeiten!

...
nicht jeder nutzt die GNOME-Shell
...
Wenn ich mit der Komplexität falsch liege, beweisen Sie mir bitte, dass ich falsch lag.

@HarryMichal Ich glaube, Ihre Bedenken sind unnötig.
Heutzutage sind .desktop-Dateien und Icon-Datei-Themen so konzipiert, dass sie Desktop-unabhängig sind und den XDG-Spezifikationen unterliegen:
https://spezifikationen.freedesktop.org/
https://specifications.freedesktop.org/desktop-entry-spec/latest/index.html
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

An alle:
können wir die benötigte Funktionalität vielleicht als DNF Plugin entwerfen?

PS: Ich habe gerade festgestellt, dass Flatpak bereits Apps verfügbar macht, sodass wir bei Bedarf einfach den Code ausleihen können.

Ich muss noch eine Deinstallationsfunktion hinzufügen, scheint aber nicht zu schwer zu sein.

Danke @A6GibKm , bitte! :)