Toolbox: Integración de archivos de escritorio

Creado en 21 abr. 2020  ·  18Comentarios  ·  Fuente: containers/toolbox

Si instala una aplicación GUI (por ejemplo, VS Code, GNOME Builder, etc.), creará un archivo de escritorio en / usr / share / applications. Pero la caja de herramientas tiene un sistema aislado (excepto homedir) y no se unirá.
Si puede haber una opción para crear un archivo de escritorio a partir de él, como:
$ toolbox desktop code.desktop servirá:

  1. Copie /usr/share/applications/code.desktop a .local / share / applications / toolbox_code.desktop
  2. Cambie todas las referencias ejecutables (/ usr / bin / code o code) a los contenedores (/ usr / bin / code -> toolbox run / usr / bin / code, etcétera)
  3. Copiar el icono al almacenamiento de iconos local

También agregue la opción para eliminar:
$ toolbox desktop code.desktop -r
para eliminar ~ / .local / share / applications / toolbox_code.desktop y el icono

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

Comentario más útil

¡Voy a por ello!

Todos 18 comentarios

¡Hola @ oksoft-git! Esto parece interesante. Estaba pensando en ofrecer algo similar a esto. ¿Le gustaría hacer un PR con esta función (pero no en Shell sino en Go para la nueva versión de Toolbox ?

@debarshiray , ¿qué opinas?

¡Voy a por ello!

Esta característica beneficiaría enormemente a los usuarios de silverblue porque entonces puede usar fácilmente las aplicaciones del contenedor.

¿Sería posible incluir integración binaria básica, para permitirle exportar envoltorios de comandos básicos al sistema base o eso está fuera del alcance del proyecto?

Como envoltorios de comandos me refiero a un envoltorio como este para nano, por ejemplo (puede ser más complejo que esto para algunos programas)

!/bin/bash
toolbox nano "$@"

(Flatpak hace algo como esto, podría investigarlo más a fondo)

¡Hola @sandorex ! La característica de la que está hablando ya se está rastreando aquí: # 145. Es una de las prioridades después de implementar la Caja de herramientas actualizada. Si bien estas dos características son similares, la solución a ellas es muy diferente.

Ahora me pregunto si darle a Toolbox el poder de crear / editar archivos .desktop para aplicaciones es realmente el camino a seguir. Requeriría que Toolbox supiera dónde ubicar el archivo .desktop existente, encontrar las líneas correctas, actualizarlas y mover / copiar el archivo a una ubicación donde el escritorio (no todos usan GNOME Shell) lo encontrará y lo usará. Esto me parece una gran parte de la lógica innecesariamente que no sería de mucha utilidad.

En cambio, la sección de la documentación con instrucciones sobre cómo actualizar un archivo .desktop existente me suena mejor.

Si me equivoco acerca de la complejidad, entonces, por favor, demuestre que estoy equivocado.

Puedo estar equivocado, pero los archivos de escritorio se buscan de forma recursiva en ~/.local/share/applications por lo que un directorio que contiene solo archivos de escritorio de la caja de herramientas (por contenedor) y luego simplemente elimina los archivos de escritorio que no existen en el contenedor, pero la modificación realmente no puedo simplificar

El segundo enfoque sería darle esta responsabilidad a otra aplicación ( toolbox-desktop-integration ) que permitiría la selección de archivos de escritorio para llevarlos al host (ponerlos en sus carpetas sería inteligente, como ~/.local/share/applications/_toolbox_XXX donde XXX es el nombre del contenedor)

Interesado en tu opinión @HarryMichal

Está casi hecho, pero no puedo extraer la ruta del icono del archivo del escritorio para copiarla en el host.

_edit_: Será mejor crear una herramienta dedicada. Lo recrearé.

@ ondra05 ¡

Hay una cosa que personalmente mejoraría (aunque no es necesario) y es usar cat para leer el archivo del contenedor, funcionará bien pero es un poco hacky, porque podman comparte imágenes con toolbox puede usar podman cp para copiar archivos entre el contenedor y el host

He estado jugando con esta idea en este script de Python. Actualmente instala archivos de escritorio, iconos, mime y metainfo. Todavía tengo que agregar una función de desinstalación, pero no parece demasiado difícil.

Lamentablemente, no tengo tiempo para hacer una aplicación adecuada, hice la interfaz de usuario, pero GTK es solo un dolor en el trasero, probablemente algún día haga la aplicación CLI solo (con suerte)

Lamentablemente, no tengo tiempo para hacer una aplicación adecuada.

Creo que una GUI para esto es excesiva. En mi humilde opinión, esto debe manejarse con comandos en la dirección de toolbox export con banderas como --remove y --list .

Intentaré investigarlo. Me pregunto si es posible agregar un comando toolbox export APP que llame, digamos, a este script de Python dentro de la caja de herramientas de manera similar a toolbox run export.py ARGS . Si bien es claramente mejor hacerlo en marcha, esto solo implica copiar archivos desde /usr de la caja de herramientas a $XDG_DATA_DIR y podría ser más sencillo usar un script para ello. No sé cuál es el mantenedor de esta posibilidad.

Tenga en cuenta que dicha extensión tendría que tener en cuenta muchas cosas, por ejemplo, el problema de manejar iconos no es trivial.

Esto es similar a la discusión sobre la adición del comando de ejecución , incluida esta conversación de IRC de #silverblue en 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.

Ya es posible agregar toolbox run emacs en el archivo .desktop para la aplicación instalada dentro del contenedor. Tener un comando que realmente analiza y crea archivos .desktop es otro paso en esa misma dirección, y no estoy seguro de si es un paso demasiado lejos.

@debarshiray ¿qué piensas de un script de Python que copia archivos de escritorio, icondata y metadata? Ya hice uno y está funcionando bien.

Definitivamente es una forma de hacerlo. Sin embargo, dudo en incluirlo en Toolbox en este momento.

¡Estoy interesado en trabajar en este tema!

...
no todo el mundo usa GNOME Shell
...
Si me equivoco acerca de la complejidad, entonces, por favor, demuestre que estoy equivocado.

@HarryMichal Creo que sus preocupaciones son innecesarias.
Hoy en día, los archivos .desktop y los temas de archivos de iconos están diseñados para ser independientes del escritorio y sujetos a las especificaciones 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

A todos:
¿Podemos diseñar la funcionalidad necesaria como DNF plugin tal vez?

PD: me acabo de dar cuenta de que Flatpak ya expone aplicaciones, por lo que podríamos pedir prestado su código si es necesario.

Todavía tengo que agregar una función de desinstalación, pero no parece demasiado difícil.

Gracias @ A6GibKm , ¡hazlo! :)

¿Fue útil esta página
0 / 5 - 0 calificaciones