Toolbox: Интеграция файлов рабочего стола

Созданный на 21 апр. 2020  ·  18Комментарии  ·  Источник: containers/toolbox

Если вы устанавливаете приложение с графическим интерфейсом (например, VS Code, GNOME Builder и т. Д.), Оно создаст файл рабочего стола в / usr / share / applications. Но у Toolbox есть изолированная система (кроме homedir), и она не привязывается.
Если есть возможность создать из него файл рабочего стола, например:
$ toolbox desktop code.desktop подойдет:

  1. Скопируйте /usr/share/applications/code.desktop в .local / share / applications / toolbox_code.desktop
  2. Измените все исполняемые ссылки (/ usr / bin / code или code) на контейнеры (/ 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. Это один из приоритетов после развертывания обновленного Toolbox. Хотя эти две функции похожи, решение для них очень разное.

Теперь мне интересно, действительно ли дать 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 Отличная работа!

Есть одна вещь, которую я лично улучшил бы (хотя это не обязательно), и это использование cat для чтения файла из контейнера, он будет работать нормально, но это своего рода хакерство, потому что podman делится изображениями с toolbox вы можете использовать podman cp для копирования файлов между контейнером и хостом

Я играл с этой идеей в этом скрипте Python. В настоящее время он устанавливает файлы рабочего стола, значки, mime и метаинфо. Мне еще предстоит добавить функцию удаления, но это не кажется слишком сложным.

К сожалению, у меня нет времени на создание правильного приложения, я создал пользовательский интерфейс, но GTK - это просто заноза в заднице, я, вероятно, когда-нибудь сделаю только приложение CLI (надеюсь)

К сожалению, у меня нет времени на создание подходящего приложения

Я думаю, что графический интерфейс для этого - излишество. Имхо, это следует обрабатывать командами в направлении toolbox export с флагами --remove и --list .

Я постараюсь разобраться в этом. Интересно, можно ли просто добавить команду toolbox export APP которая вызывает, скажем, этот скрипт python внутри панели инструментов аналогично toolbox run export.py ARGS . Хотя явно лучше сделать это на ходу, это включает только копирование файлов из панели инструментов /usr в $XDG_DATA_DIR и может быть проще использовать для этого сценарий. Я не знаю, что поддерживает эту возможность.

Обратите внимание, что такое расширение должно учитывать многие вещи, например, проблема обработки значков нетривиальна.

Это похоже на обсуждение добавления команды run , включая этот диалог IRC из #silverblue на 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.

Уже можно добавить toolbox run emacs в файл .desktop для приложения, установленного внутри контейнера. Наличие команды, которая фактически анализирует и создает файлы .desktop, - это еще один шаг в том же направлении, и я не уверен, что это еще на один шаг слишком далеко.

@debarshiray что вы думаете о скрипте Python, который копирует файлы рабочего стола, icondata и метаданные? Я уже сделал один, и он работает нормально.

Это определенно один из способов. Однако я не решаюсь включать его в Toolbox прямо сейчас.

Мне интересно поработать над этим вопросом!

...
не все используют GNOME Shell
...
Если я ошибаюсь насчет сложности, то, пожалуйста, докажите, что я не прав.

@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 рейтинги