Toolbox: Intégration de fichiers de bureau

Salut @oksoft-git ! Cela semble intéressant. Je pensais proposer quelque chose de similaire. Voudriez-vous faire un PR avec cette fonctionnalité (mais pas en Shell mais en Go pour la nouvelle version de Toolbox ?

@debarshiray , qu'en pensez-vous ?

Je me lance!

Cette fonctionnalité profiterait grandement aux utilisateurs de silverblue car vous pouvez alors facilement utiliser les applications du conteneur

Serait-il possible d'inclure une intégration binaire de base, pour lui permettre d'exporter des enveloppes de commandes de base vers le système de base ou est-ce hors de portée du projet ?

En tant que wrappers de commandes, je veux dire wrapper comme celui-ci pour nano par exemple (cela peut être plus complexe que cela pour certains programmes)

!/bin/bash
toolbox nano "$@"

(flatpak fait quelque chose comme ça, pourrait approfondir)

Salut @sandorex ! La fonctionnalité dont vous parlez est déjà suivie ici : #145. C'est l'une des priorités après le déploiement de la boîte à outils mise à jour. Bien que ces deux fonctionnalités soient similaires, leur solution est très différente.

Je me demande maintenant si donner à Toolbox le pouvoir de créer/modifier des fichiers .desktop pour les applications est vraiment la voie à suivre. Il faudrait que Toolbox sache où localiser le fichier .desktop existant, trouve les bonnes lignes, les met à jour et déplace/copie le fichier vers un emplacement où le bureau (tout le monde n'utilise pas GNOME Shell) le trouvera et l'utilisera. Cela me semble être un gros morceau de logique inutile qui ne serait pas très utile.

Au lieu de cela, la section de la documentation avec des instructions sur la mise à jour d'un fichier .desktop existant me semble mieux.

Si je me trompe sur la complexité, alors, s'il vous plaît, prouvez-moi que j'ai tort.

Je me trompe peut-être, mais les fichiers de bureau sont recherchés de manière récursive dans ~/.local/share/applications donc un répertoire qui contient uniquement les fichiers de bureau de la boîte à outils (par conteneur), puis supprimez simplement les fichiers de bureau qui n'existent pas dans le conteneur mais la modification que je ne peux pas vraiment simplifier

La deuxième approche serait de confier cette responsabilité à une autre application ( toolbox-desktop-integration ) qui permettrait la sélection de fichiers de bureau à apporter à l'hôte (les mettre dans leurs dossiers serait intelligent, comme ~/.local/share/applications/_toolbox_XXX où XXX est le nom du conteneur)

Intéressé par votre avis @HarryMichal

https://github.com/ondra05/toolbox

C'est presque terminé, mais je ne peux pas extraire le chemin de l'icône du fichier du bureau pour le copier sur l'hôte.

_edit_ : Créer un outil dédié pour cela sera mieux. Je vais le recréer.

Eh bien, je l'ai. github.com/ondra05/toolbox-desktop

@ondra05 Excellent travail !

Il y a une chose que j'améliorerais personnellement (ce n'est pas nécessaire cependant) et c'est d'utiliser cat pour lire le fichier à partir du conteneur, cela fonctionnera bien mais c'est un peu bidon, car podman partage des images avec toolbox vous pouvez utiliser podman cp pour copier des fichiers entre le conteneur et l'hôte

J'ai joué avec cette idée dans ce script python. Actuellement, il installe des fichiers de bureau, des icônes, des mimes et des méta-infos. Je n'ai pas encore ajouté de fonctionnalité de désinstallation, mais cela ne semble pas trop difficile.

Je n'ai malheureusement pas le temps de faire une application appropriée, j'ai créé l'interface utilisateur mais GTK est juste une douleur dans le cul, je ne ferai probablement qu'une application CLI un jour (espérons-le)

Je n'ai malheureusement pas le temps de faire une application appropriée

Je pense qu'une interface graphique pour cela est exagérée. À mon humble avis, cela devrait être géré avec des commandes dans le sens de toolbox export avec des indicateurs tels que --remove et --list .

Je vais essayer de me renseigner. Je me demande s'il est possible d'ajouter simplement une commande toolbox export APP qui appelle, disons, ce script python à l'intérieur de la boîte à outils de la même manière que toolbox run export.py ARGS . Bien qu'il soit clairement préférable de le faire en go, cela implique uniquement de copier les fichiers de la boîte à outils /usr vers $XDG_DATA_DIR et il peut être plus simple d'utiliser un script pour cela. Je ne sais pas quel est le mainteneur de cette possibilité.

A noter qu'une telle extension devrait prendre en compte beaucoup de choses, le problème de gestion des icônes n'est pas trivial par exemple.

Ceci est similaire à la discussion autour de l' ajout de la commande run , y compris cette conversation IRC de #silverblue sur 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.

Il est déjà possible d'ajouter toolbox run emacs dans le fichier .desktop pour l'application installée à l'intérieur du conteneur. Avoir une commande qui analyse et crée réellement des fichiers .desktop est un autre pas dans la même direction, et je ne sais pas si c'est un pas de trop.

@debarshiray que pensez-vous d'un script python qui copie les fichiers de bureau, les icondata et les métadonnées ? J'en ai déjà fait un et ça marche très bien.

C'est certainement une façon de s'y prendre. Cependant, j'hésite à l'inclure dans Toolbox pour le moment.

Je suis intéressé à travailler sur ce problème !

...
tout le monde n'utilise pas GNOME Shell
...
Si je me trompe sur la complexité, alors, s'il vous plaît, prouvez-moi que j'ai tort.

@HarryMichal Je pense que vos préoccupations sont inutiles.
De nos jours, les fichiers .desktop et les thèmes de fichiers d'icônes sont conçus pour être indépendants du bureau et soumis aux spécifications 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

À tous:
pouvons-nous concevoir les fonctionnalités nécessaires en tant que plugin DNF ?

PS: je viens de réaliser que Flatpak expose déjà les applications afin que nous puissions simplement emprunter son code si nécessaire.

Je n'ai pas encore ajouté de fonctionnalité de désinstallation, mais cela ne semble pas trop difficile.

Merci @A6GibKm , s'il vous plaît! :)