Я думаю SELinux похож на описываемое тобой. Он ограничивает доступ приложений и служб до конкретных, только нужным им, ресурсов. Всё это ещё можно настроить вручную.

Надеюсь, что такого не существует.

Не, это не в сторону sandboxing, а в сторону обработки URL и фиксированных интерфейсов для них. Например есть намерение «поделиться фоткой». Обработчик URL share:/photo.png должен поддерживать набор интерфейсов типа RecipientList и LatestRecipients ну и т.д.

Поставь android-x86 и пользуйся его возможностями.

Прямо как ActiveX, COM, KParts, Bonobo, Orbit/CORBA?

Ark регистрируется в системе как способный открыть mimetype архивов например zip, дальше (хотя сейчас уже все меньше это используется) konqueror может встроить ark в свою вкладку открыв этот архив.

В KDE такое есть. Я не пользовался telepathy-kde давно он весь какой-то стремный заброшенный и перегруженный стал. Наверное KDE PIM интегрируется в систему лучше.

Ты про гномощель чтоли?

Плохо представляю, зачем такое может быть нужно. Регистрация обработчика URL или расширения вроде уже есть. А ты хочешь чего-то странного. Не думаю, что это многим нужно.

если приложение позволяет делиться фоточками

То можно его открыть и поделиться этими самыми фоточками. Зачем здесь какие-то интерфейсы и прочая муть?

Или, если приложение позволяет проводить навигацию по файлам, оно регистрируется как файловый менеджер.

Вообще ничего не понял. Зачем приложению регистрироваться, как файловый менеджер? Просто запусти его и всё. Вся регистрация приложения в линуксе это размещение выполняемого файла в $PATH. Ну если это GUI, то надо в /usr/share/applications или где-то там создать специальный файл.

Скорее, как следующее поколение обработчиков mime. По-сути текущие спеки freedesktop говорят как сделать соотношение какой программой должен открываться какой тип ресурсов. А тут речь про то, какие программы могут обрабатывать намерение пользователя. Ключевая особенность тут в том, что действия по обработке могут быть сложнее чем открытие и могут иметь как входы, так и выходы.

Яркий пример приложения для подобного протокола - диалог поделиться в android 6+. Там показывается список каналов через которые можно поделиться например: мыло, телега и шматрица, оно отсортировано по наиболее частым способам. Эту часть - можно реализовать на одних обработчиках mime. Но помимо самых часто используемых способов поделиться, также есть наиболее частые для поделиться контакты. Для реализации этой части - протокола обработки спецификаций mime уже недостаточно, либо я не очень понимаю как.

Следующим за твоим постом отписал подробнее пример. Если есть понимание как текущими протоколами можно отделаться для реализации такого ПО, с удовольствием почитаю.

Ты путаешь хочу андроед и хочу как в андроед.

То можно его открыть и поделиться этими самыми фоточками. Зачем здесь какие-то интерфейсы и прочая муть?

Чтобы в другом приложении можно было сделать вызов «поделиться фоткой» а пользователь выбрал с кем и через что поделиться через единый интерфейс.

Например, пресловутая кнопка «отправить» в nautilus могла бы быть в разы функциональней.

Ну вот в kde/kparts насколько я понимаю есть статичные файлы описаний вроде бы json что данный parts умеет делать.

Там показывается список каналов через которые можно поделиться

Это нужно чтобы как-то информация у системы появилась, то есть один раз телеграм нужно запустить, авторизоваться, затем он уже делится с системой что он умеет. Ведь программу можно выгрузить из памяти но эти «действия» так и должны остаться где-то сохранены. Можно класть json+png файлы в директории, можно отдавать по dbus и пусть система сама эту информацию хранит.

А если условная телега закрыта то надо как-то в этой же телеге реализовать запуск с параметрами argc argv типа /usr/bin/telegram --contact id --send-file /home/user/kakashka.jpg

Например, пресловутая кнопка «отправить» в nautilus могла бы быть в разы функциональней.

Для этого нужно «улучшить» эту кнопку отправить в nautilus и чтобы софт реализовал поддержку этих «улучшений» у себя но без спецификации ничего не выйдет.

В той же венде, по отправить https://i.imgur.com/IFhbuMU.png запускается окно в которое могут интегрироваться программы.

Лично я не понимаю в принципе, зачем этот функционал на десктопе. Я им и на телефоне не пользуюсь, если честно, но там я хотя бы мотивацию могу понять - буфер обмена там уродский, файлы там уродские. Но на десктопе я либо делаю ctrl+c, alt-tab, ctrl+v, что занимает условно секунду. Либо я просто загружаю файл с диска в нужную программу. Это гораздо быстрей, удобней и привычней, чем пользоваться какими-то средствами для «поделиться».

Тут нужна инверсия зависимостей уровня mime database + DE. Только более функциональная, по-сути нужно помимо обработчика URI ещё d-bus endpoint для обращения к нужным интерфейсам. Например, для приложений которые не подеживают нужные интерфейсы но могут обрабатывать условную схему share://<resource uri> то для них можно сделать и обёртку дефолтную.

Проблема с открытием условной телеги решается уже сейчас на уровне спецификаци xdg desktop entry.

Дык и я про что, но пока-что я не вижу не то, что готовой софтины, но даже протокола для неё или работ по нему.

пресловутая кнопка «отправить»

Хороший пример. В винде она тоже есть. Типа щёлкаешь правой кнопкой по файлу, выбираешь «отправить», выбираешь там дискету. Помню. Но дело в том, что этот функционал абсолютно излишний. У тебя справа в навигаторе эта дискета, просто перетащи на неё файл и всё. Или перетащи файл в открытое окно отправки письма и он добавится как приложение в это письмо. Или перетащи его в чат и он отправится собеседнику. Это то, что на десктопе за счёт использования мышки делается тривиально. Просто нет нужды в мобильном интерфейсе.

Если говорить об использовании гнома на планшете, о чём, судя по всему, неимоверно мечтают все его разработчики, тут вопрос другой. Но я так и не понимаю, на каком планшете они его собираются использовать, недавно искал, не нашёл ни одного планшета в магазине с гномом. Продавцы про такой даже не слышали, говорят или айпады или андроиды, других не бывает.

Ну, это сильно зависит от флоу, мне например удобней запомнить один интерфейс, чем 100500 в каждом отдельном случае. Хоткеи здесь - это уже уровень реализации, ничто не мешает сделать дефолтный для DE окружения хоткей для «поделиться/отправить». Вот как ты быстро отправляешь скриншот в телегу или другой мессенджер? А фотку?

Там выше товарищ отписал про свежую кнопку отправить в винде:)

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

Но это мы рассмотрели только кейс из «проводника». А ведь проводник из этой схемы можно совсем исключить позволяя любому приложению делиться созданным ресурсом «напрямую».

Да и сам кейс «поделиться» это только один пример, хоть и наиболее яркий из приходящих на ум для использования протокола намерений.

это как в ios, там нет файлов как таковых по этому приложения шарят информацию между собоей через специальные интерфейсы, приложение А говорит «я умею шарить такие то данные», а приложение Б говорит «я умею принимать такие то данные».

вот еще пример какой-нибудь «напоминатель» из какого-нибудь PIM, в zoho, google (наверное и в яндексе тоже) это все есть, но оно там гвоздями прибито к их инфраструктуре и их интеграциями: выделяешь текст в браузере - пкм - напомнить тогда-то, другое приложение не важно какое (браузер об этом ничего не знает) получает текст и дату.

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

• предложить список контактов для отправки(рекомендации может строить как средство отправки…)
• принять ресурс на отправку
• вернуть объект контакт который пользователь выбрал для отправки(…так и прокси-интерфейс унифицирующий процесс отправки)

как ты быстро отправляешь скриншот

Print Screen, альт-таб, Ctrl+V, Enter.

А фотку?

Если открыт файловый менеджер - перетащу в окно чата из него. Если не открыт, значит нажму кнопку «Отправить файл» и в диалоге выберу эту фотку.

Т.е. надо помнить что картинки в один и тот же чятик надо скидывать по-разному из разных мест. Представь что ты находясь в скриншот-туле, просмоторщике фото или проводнике жал условный super+s и жмякая enter отправлял бы фоточку в чатик в котором было последнее сообщение?

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

Там выше товарищ отписал про свежую кнопку отправить в винде:)

Ну я уже объяснил, что смысла в этом 0, на мой взгляд. В винде, видимо, огрызки от их попытки сделать Windows Mobile. Ну и вроде есть ноутбуки-трансформеры, где винда работает как бы на планшете. Там в винде если поискать, можно найти эти огрызки мобильного функционала, которые на десктопе не нужны от слова совсем.

Перетаскивать - оооочень доооолго

Почему это долго? Я перемещаю курсор от одного края экрана до другого за долю секунды. Куда уж быстрей. По диалогам я кликаю точно дольше.

Но это мы рассмотрели только кейс из «проводника». А ведь проводник из этой схемы можно совсем исключить позволяя любому приложению делиться созданным ресурсом «напрямую».

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

Да и сам кейс «поделиться» это только один пример, хоть и наиболее яркий из приходящих на ум для использования протокола намерений.

Вот что было бы неплохо - это возможность регистрировать не одно приложение для обработки URL, а несколько. И системный диалог по выбору нужного приложения. Ну и подумать и стандартизовать нужные схемы.

Т.е. как я это хотел бы видеть. Я открываю, например, почту. В почте мне пришёл url вида coordinates://earth/51.1458479-71.4322685. На этот URL зарегистрированы Gnome Maps, Google Earth и несколько сайтов в браузере, например Google Maps, Yandex Maps, 2GIS. И я выбираю из этого списка нужное приложение по щелчку. Вот это было бы лично мне довольно удобно. Думаю можно и «отправить» прикрутить по этой схеме, главное про форматы URL договориться, а то с этим беда, даже для координат на карте до сих пор стандартной схемы нет.

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

это возможность регистрировать не одно приложение для обработки URL

Эта возможность как раз есть. Подчеркну есть спека позволяющая реализовать такой софт который будет работать во всех дистрах, а не сам лаунчер:) Есть xdg-open который по-сути и есть точка входа для подобного функционала. Есть зачатки этого функционала в различных «открыть с помощью» в firefox и nautilus, хотя единый интерфейс конечно был-бы удобней и снимал бы нагрузку по работе с mime-databse с приложений на пользу ОС.

Но спеки которая позволяла бы делать более продвинутые сценарии я пока не нашёл.

да все это должно быть доступно как в динамическом варианте, так и в ситуации когда программа еще не была запущена после перезагрузки ОС но не ограничеваться банальными опциями, а иметь варианты до перезагрузки, по идее кеш в ~/.cache или ~/.local из временных данных.

По факту их кто-то реализует, кто-то не реализует и в итоге все будут делать так же, как раньше.

С одной стороны - оно скорее всего так и будет, всегда так происходит. С другой стороны - mime и URI как-то прижились по-итогу:)

Ну и наблюдаемая тенденция в том, что реализации есть везде кроме онтопика, API почти у всех, но везде кроме андрюши оно специфичное для одного намерения(intent) один API другого другой, а открытого протокола не привязанного к API вообще нет.

А смысл это выносить за пределы двух сущностей:

• сам обработчик (как-то куда-то записал куда ты чаще всего скидываешь фоточки и куда последний раз скидывал фоточки или с кем трещал, или любую другую статистику для построения рекомендации)
• прокси (записал через что и кому ты последний раз скидывал фоточки и через что и кому/куда ты чаще всего их скидываешь)

?

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

А, или ты пытаешься уже протокол придумать построенный на стандартных директориях из XDG? Ну вот кажется, что формализация отношений на уровне раскрытия инфы специфичной для выбора рекомендации выглядит избыточной. Т.е. имеет смысл хранить только сами рекомендации тогда, это кстати будет вполне в духе freedesktop, хотя в реализации будет местами сложнее т.к. API будет полагаться на штуки типа inotify. Да и на каждое изменение состояния приложения нужно будет производить дисковый ввод вывод (написал в чатик А - рекомендация поменялась, написал в чатик Б - рекомендация о5 поменялась).

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

С чего бы? Будет запрос через d-bus на заданный интерфейс приложения «дай рекомендации». Это хорошая альтернатива обмену рекомендациями через интерфейс файловой системы хотя бы потому, что не требует постоянного её изменения сохраняя отличное время обновления рекомендаций правда за счёт увеличения времени первого доступа к рекомендациям.

Только взаимодействие через D-Bus. Никакое API языков программирования c, c++, python, etc для этого не подойдет, снова будет 1 в 1 ситуация как с Tray/AppIndicator в современном линуксе и куча их реализаций, вон минтовцы новую реализацию свою сделали в итоге в их трее разные значки от разных приложений от API библиотек qt/gtk/indicator.

Ещё - такой подход мотивирует отделять логику приложения от UI кстати.

NIH синдром, это проблема когнитивного расстройства сообщества а не спеки :)

Можно конечно отдать проблему постоянной перезаписи на откуп уже развитой файловой подсистеме, но придётся всё равно разрабатывать протокол уровня базы данных с локами, транзакциями и т.п., другими словами - транспорт, и реализовывать его в API так или иначе для всех языков т.к. руками это трогать смогут 2.5 человека, если хочется сохранить возможность возвращать результаты обработки. В случае d-bus этого делать не придётся.

Собственно d-bus и решает проблему транспорта, в случае двустороннего взаимодействия придётся переизобретать транспорт, не очень понятно, зачем это нужно.

Я и говорю dbus, inotify не пойдет, да разработчикам ничего не нужно в файлы самостоятельно писать, выше я не прав, просто desktop файл.

В KDE kparts https://github.com/KDE/ark/blob/master/part/ark_part.desktop.cmake#L151 регистрируется вот так для поддерживаемых MimeType. По идее нормально да, но для «последних контактов» это не подходит нужно хранить кеш этих контактов между перезагрузками, ну это пусть «улучшенный плагин» наутилуса делает.

А, дык идея в том, что как «улучшенный плагин» так и «телега» должны хранить кэш. А при старте системы «плагин» может быть и просто запускаемым через exec приложением обработчиком схемы шаринга. А вот «телега» должна быть готовой отвечать на dbus запросы. Хотя если плагин будет dbus activable ничего страшного тоже не произойдёт, за исключением того, что не удобно будет из терминала его звать.

Но идею я понял, в кедах есть уже похожий протокол в виде расширения desktop entry. По сути нужен ключ уровня:

# ...
X-Intent=share
X-Intent-Dbus-Endpoint=org.dbus.telegram.share
# ...

А для плагина:

MimeType=x-scheme-handler/intent-share

Ну и спека на возможные значения X-Intent и требуемые для поддержки каждого значения интерфейсы которые должны быть доступны по X-Intent-Dbus-Endpoint.

URI мог бы выглядеть следующим образом:

intent-share:<URI>

например:

intent-share:file://home/pon4ik/porn.png

Бери да интегрируйся - делов то.

# postr.desktop - Integrate postr into
#                 the "Send To" menu.
[Desktop Entry]
Type=Application
Version=1.0
Encoding=UTF-8
TryExec=postr
Exec=postr %F
Icon=postr
Name=Flickr
MimeType=image/jpeg;

https://docs.xfce.org/xfce/thunar/send-to

https://specifications.freedesktop.org/basedir-spec/latest/

О_о а почему в наутилос такое не завезли?

Ааа… понятноооо почему. Потому, что это совместимо только с thunar.

Смотри, ты листал котограмм и нашёл картинку с котиком. Он тебе понравился и ты решил поделится с подружкой, нажимаешь кнопку пошарить и тебе система выкидывает список приложений которые умеют а) шарить, б) принимают картинки. Вот это построение списка основано на том что указал разработчик приложения котограмм как намерение (шарить) при нажатии на соответствующую кнопку( а могло быть печатать, или редактировать) и на тех интерфейсах, которые приложения зарегистрировали в системе при установке. Т.е. запустив тот же ватсапп ты не можешь отправить котика, потому что у тебя фотка в другом приложении, а не файл на диске

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

Не хочу как в андроед

Не ставлю целью обидеть, но тебе смартфон прямо в коляску клали? На настоящем компьютере доступ не залочен и я и так могу запускать любые программы и манипулировать данными непосредственно без всяких чережжопных протоколов. (Не беря в расчёт всякое дерьмо типа снапов/флатпаков, которое ставит целью зачем-то попрятать от меня мои же файлы, но к огромному счастью оно не взлетело даже среди энтузиастов.)

Потому, что это совместимо только с thunar.

Возможно, классическое unix-like решение - простое и рабочее, возможно, с ограничениями. А в наутилусе скорее всего какой-нить windows-like dbus - сложное и громоздкое.

Я и не обижаюсь:) Вообще думаю надо нам с лорчиком завязывать и переходить в чатики в telnet, все эти протоколы громоздкие - это от лукавого.

Я не про саму реализацию, просто, когда ты мне скинул ссылку на freedesktop я раскатал губу в сторону того, что есть уже протокол для шаринга и просто наутилус в него не умеет.

Когда я кидал ссылку я тоже был уверен +) ибо в ссылке на freedesktop засветилось «наше фсё» lennart@poettering.net +))) + я это уже очень давно использую - просто и удобно. Но почитал потом увидел, что это про другое. Развивают и протаскивают в стандарт всякое другое, а не подобные простые и удобные вещи.

Очень надеюсь что в линуксе такой заразы не появится.