Зачем нужно xdg-desktop-portal?

1. Нужно, чтобы в dolphin работало правое меню «open with»

2. Потому что нужен xdg-desktop-portal

Если у меня X11, и нет flatpak, оно мне вообще нужно?

Можно запускать десктопный софт в контейнерах, если он умеет в порталы.

Пиши есчо побольше бесполезных комментариев.

xdg-desktop-portal/testing 1.16.0-2 amd64
  desktop integration portal for Flatpak and Snap

Почему без него в dolphin не работает правое меню «open with»?

Потому что большая часть софта из KDE - это бажный и хреново спроектированный хлам, использование которого может оправдать только его взаимная интеграция (и мб возможность кастомизации тулбаров, в отдельных случаях).

Если у меня X11, и нет flatpak, оно мне вообще нужно?

Иногда бывает нужно, если ты запускаешь GTK приложения в KDE и хочешь, чтобы они использовали стандартные кодоешные файловые диалоги вместо урезанных гномовских. Например у меня по умолчанию Visual Studio Code использует гномодиалоги для открытия папок и файлов. Но если поставить xdg-desktop-portal-kde и запустить вскод с переменной окружения GTK_USE_PORTAL=1, то он начинает использовать KDE диалоги. Но далеко не весь GTK софт использует порталы. Гимп например такого до сих пор не умеет.

А так да, порталы изначально разрабатывались для флатпак приложений и без флатпака особого смысла не имеют. Нативные файловые диалоги в GTK приложениях - это всего лишь полезный побочный эффект.

aptitude show xdg-desktop-portal
Пакет: xdg-desktop-portal                        
Версия: 1.8.1-1
Состояние: установлен
Установлен автоматически: да
Мультиархитектура: сторонняя
Приоритет: необязательный
Раздел: admin
Сопровождающий: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
Архитектура: amd64
Размер в распакованном виде: 1 459 k

Ого, целых 1,5 мегабайта на диске. Наверно на флешку на 128 мегабайт устанавливаешь.

без флатпака особого смысла не имеют

Под вяленым через них реализуют шаринг экрана во всяких зумах, без флатпака. Правда по опыту это, скорее, не работает, чем работает, но может у меня слишком кривые руки чтобы это завести

Только непонятно почему Dolphin меню «Open with...» не работает без этого пакета. На Debian testing.

Ого, целых 1,5 мегабайта на диске

До чего унылый аргумент.

На самом деле отличный аргумент. Не, ну ведь разумеется создатели софта должны думать о тараканах в голове у каждого поехавшего. Кому-то блютуз ненужен, кому-то вай-фай, кто-то не пользуется захватом экрана, у кого-то тулкитофобия в острой стадии. Под каждого не подстроиться. И уж 1,5 мегабайта в такой ситуации совершенно не проблема.

Так это ты же пишешь о каких-то мегабайтах. У тебя эти тараканы в голове и есть.

Кстате не подскажешь какая зависимость размера на диске и размера в оперативной памяти, если уж ты такой умный.

Под вяленым через них реализуют шаринг экрана во всяких зумах, без флатпака. Правда по опыту это, скорее, не работает, чем работает

Да, точно, под вяленым используются порталы и pipewire. Помню в ковидные 20-21 годы видеозвонки в зуме и скайпе под вяленым у меня не работали от слова совсем, что окончательно отбило охоту пробовать wayland сессии. Как сейчас не знаю. Возможно уже допилили.

Только непонятно почему Dolphin меню «Open with…» не работает без этого пакета. На Debian testing.

Да хрен его знает. Нагуглил вот такой баг:

https://bugs.kde.org/show_bug.cgi?id=466148

Особо не вникал, но судя по всему разрабы Dolphin выпилили старый диалог «Open with» и поменяли его на новый диалог, который открывается только через портал и требует пакет xdg-desktop-portal в обязательном порядке. К багу приложены скриншоты старого диалога «Open with» из Krusader и нового портального диалога из Dolphin. Видно, что окошки совершенно разные.

Проблему починили в плазме 5.27.1. Ну как починили. Просто добавили xdg-desktop-portal в обязательные зависимости :) Так что хочешь не хочешь, а пакет все равно придется поставить.

Просто добавили xdg-desktop-portal в обязательные зависимости

Отличное решение. Хорошо что все нужные мне пакеты собираются без плазмы.

Пздц гении.

Баг «исправлял» видимо тот чувак выше, который про мегабайты писал.

и без флатпака особого смысла не имеют

ИИМХО неправильное утверждение. По большому счёту, портал - это стандартизированный (важно) IPC-интерфейс (в Линукс D-BUS, а что ещё-то, собственно) и какая-то хрень за ним, что-то там сама себе делающая и общающаяся с вызывающим через этот интерфейс. В чём смысл: у нас есть единая удобная точка контроля доступа к ресурсу - интерфейс.

Почему тут и pipewire сгодился, для скринкастов: потому что его интерфейсы абстрагированы в файловые дескрипторы (fd), которые легко и пробрасываются по шине и контролирются.

Почему и диалоги разные можно использовать: потому что интерфейсу портала, в принцие, пофигу, что реализуется там в бэкенде, как и бэкенду пофигу, что его вызывает. Если совсем упростить, достаточно в интерфейс постучаться. Но бэкенды таки должны быть (кто серверную часть портала реализовывать-то будет), поэтому xdg-desktop-portal-kde/gnome/wlr и тд.

Портал - это стандартизированный (важно) IPC-интерфейс

Это хорошо

в Линукс D-BUS, а что ещё-то, собственно

А привзяка к копротехнологии «D-Bus» - это плохо. Если бы оно работало через обычные unix-сокеты или какую-то адекватную шину (предподчтительно, но не обязательно, реализованную на уровне ядра), то было бы зашибись.

это плохо

Де-факто стандартный высокоуроневый IPC в Линукс. Другого нет.

Если бы оно работало через обычные unix-сокеты

Так D-Bus через них и работает, собственно. Тамже фишка, собственно в сериализации и доставке.

копротехнологии

Да сойдёт. С обвязками кодить нормально. А вот демон - это да. Я всё жду, когда его на хороший-годный dbus-broker повсеместно заменят.

Другого нет.

Как минимум, zeromq есть. Но я все-таки надеюсь, что Гугол подкатит замену для Android Binder и kdbus, которая устроит всех и будет использовать адекватный протокол, и тогда d-bus наконец-то отправится на свалку истории.

Так это ты же пишешь о каких-то мегабайтах. У тебя эти тараканы в голове и есть.

Чего? Это что за глупости? Это же тебя беспокоит 1,5 мегабайта на жестком диске ненужного лично тебе, но нужного много кому еще пакета. Кстати, там еще сотни и сотни пакетов, которые возможно тебе не нужны, тоже можешь попереживать о них.

Кстате не подскажешь какая зависимость размера на диске и размера в оперативной памяти, если уж ты такой умный.

Не подскажу. Но можешь поделиться своими наблюдениями.

Чего? Это что за глупости? Это же тебя беспокоит 1,5 мегабайта на жестком диске ненужного лично тебе, но нужного много кому еще пакета.

Это тебя беспокоят какие-то 1.5 мегабайта на диске. Это же ты уже третий раз об этом пишешь, я об этом _ни_разу_ не писал.

Кстати, там еще сотни и сотни пакетов, которые возможно тебе не нужны, тоже можешь попереживать о них.

Вот вот, смотри не переживай там сильно.

По большому счёту, портал - это стандартизированный (важно) IPC-интерфейс (в Линукс D-BUS, а что ещё-то, собственно) и какая-то хрень за ним, что-то там сама себе делающая и общающаяся с вызывающим через этот интерфейс.

Согласен. Я имел в виду, что система порталов разрабатывалась в первую очередь для контейнеризации, а потом ее постфактум начали использовать для вяленого и прикручивать портальное API к приложениям. Так-то раньше все прекрасно жили без порталов. Файловые диалоги открывались через какие-нибудь KFileDialog/GtkFileChooser. Скринкасты делались через расширения иксов. И только после того, как флатпак и вяленый набрали относительную популярность, разработчикам приложений пришлось задуматься: а) как собрать флатпак версию приложения и выложить ее на флатхаб б) как запустить приложение нативно под вяленым, а не через XWayland. Вот они и начали переводить свои приложения на портальное API. Думаю, если бы флатпак и вяленый не взлетели, то большинство разработчиков даже не стали бы заморачиваться с портальным API. Сами по себе (т.е. вне экосистемы флатпака и вяленого) порталы в общем-то особого смысла не имеют. Все нормально работало и без них.

В чём смысл: у нас есть единая удобная точка контроля доступа к ресурсу - интерфейс.

И это хорошо. Возможно десктопный онтопик со временем придет к полной изоляции приложений по умолчанию и системе рантайм пермишенов, как в андроиде. Ну например запускаешь ты приложение, а оно выдает стандартное окошко типа «хочу доступ к сети, папке закачек и адресной книге еще». И ты разрешаешь, если все выглядит нормально.

Кстати, оффтопну, вот сегодня пишут про Pipewire. Как я понял в WebRTC влили код, который напрямую взаимодействует с pw. Соответственно, можно будет получить все плюшки pw.

Цитата

It means PipeWire will be in charge of camera handling in Firefox (and soon Chrome) which will enable things like easier camera sharing between applications and also allow for a smooth transition from v4l to libcamera. It also makes the transition to Flatpaked browsers easier.