«Правильный» способ определения .desktop-файла для запущенного приложения

Заводишь key map, где ключ - имя запускаемого файла и хранимое значение – имя файла desktop. Всё.

org.telegram.desktop.desktop – эта форма рекомендована [https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/)

Ты точно программист?

Скажи, а в Windows ты можешь узнать по pid процесса или идентификатору окна с какого ярлыка было запущено приложение?

Ну так посмотри в коде какого-нибудь GNOME Shell, как оно отслеживает. Какой смысл спрашивать про решение задачи, которая уже решена всеми, кому было надо, и решения известны.

Скажи, а в Windows ты можешь узнать по pid процесса или идентификатору окна с какого ярлыка было запущено приложение?

В Windows ярлык по смыслу не является составной частью приложения. А в Linux *.desktop-файл является. Де-факто это элемент API.

Необходимо найти (если есть) с каким *.desktop-файлом оно ассоциировано.

Смотри, как какая-нибудь Unity DE это делает в коде. Ну или KDE. В Убунте исходно под это отдельная библиотека пилилась еще в то время, когда Убунта была пионером десктопных инноваций. Дальше не знаю, что там с этим кодом происходило, и как он в разные проекты проникал. Но учитывая, что функция отображения на панели не «окон», а «приложений» есть во всех основных DE, то задача как-то решается.

А вообще да, маразм получился. Сначала придумали «ярлыки», а потом дали этим «ярлыкам» в нагрузку элементы API. И получился звиздец. Ну как обычно в нашем любимом линуксе.

А в Linux *.desktop-файл является. Де-факто это элемент API.

Што?

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

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

procfs почему-то отображает обрезанные имена. Собственно,

Потому что comm это статическое поле в ядерной структуре описания процесса, и оно длиной в 16 байт, из которых один тратится на завершающий ноль.

Нет, не является. Это DE-шная обёртка. То есть оно не только не от линукса, но даже не во всех вариациях гуи окружений как-то учитывается.

С добрым утром. Вот неполный список того, что декларируется в desktop файле:

• В каких DE показывать приложение.
• К какой категории оно относится.
• Поддерживает ли приложение механизм Startup Notification.
• Какие MIME типы оно обрабатывет.
• Список «действий», которые умеет приложение.

И еще кучу специфичных для DE настроек.

Нет, не является. Это DE-шная обёртка. То есть оно не только не от линукса, но даже не во всех вариациях гуи окружений как-то учитывается.

У тебя логика отклеилась. Трей поддерживается не во всех DE. Значит механизм эмбедда иконок трея не является элементом API?

Но учитывая, что функция отображения на панели не «окон», а «приложений» есть во всех основных DE, то задача как-то решается.

Я не смотрел как у них сделано, но варианта два:

1) либо делают как я описал с контейнерами

2) либо пытаются угадать (ненадёжно, но обычно наверно получается правильный ответ), какой это мог бы быть ярлык (сравнивая путь к бинарнику) + эвристика по SID/PGID/PPID

Это api, но тоже DE-шное. Не линуксовое и даже не иксовое.

Удивительно, но ничего из этого не декларируется в меню whiskers и всё работает. ЧЯДНТ?

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

Это api, но тоже DE-шное. Не линуксовое и даже не иксовое.

Удивительное рядом. Оказывается, «линуксовые» и «иксовые» API это не святое что-то, а просто одни из миллионов программных междумордий, в ряду прочих.

Удивительно, но ничего из этого не декларируется в меню whiskers и всё работает. ЧЯДНТ?

Удивительно, но если нести восторженную ерунду, лишенную фактического содержания, то мир вокруг начинает быть «удивительным».

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

Там фиксированный набор метаданных, связанных не с приложением, а с параметрами его запуска. Рабочий каталог, режим совместимости и т.п.

А desktop файл ориентирован хранить метаданные самого приложения, при чем потенциально расширяемые до бесконечности.

Вполне логично, что эти метаданные приложению необходимо бывает ЗНАТЬ, а в ряде случаев еще и УПРАВЛЯТЬ ими. И вот здесь мы приходим к исторически сложившейся жопе.

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

А в модели, принятой f-d.o – ничего подобного.

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

И в .desktop то же самое. Все эти «Действия» и «MIME-типы» — для DE, чтоб знал, что приложение может делать и с чем. Самому приложению это нахрен не надо, а то, что надо, хранится в его настройках, а не в .desktop (которых, кстати, может быть вагон разных, но запускающих одно и то же).

xml файл с метаданными.

tld.app.metainfo.xml уже есть.

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

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

А есть еще проблема затенения метаданных. Обновилось приложение, в систему прилетел новый desktop файл. А в хомяке у пользователя лежит необновлённый, который имеет более высокий приоритет.

Короче, это весьма проблемная технология.

Самому приложению может быть «нахрен надо», например, добавить себя в автозагрузку или удалить из автозагрузки.

За это надо бить канделябром по башке. Ещё добавить автообновление приложения как в винде и будет комбо.

За это надо бить канделябром по башке. Ещё добавить автообновление приложения как в винде и будет комбо.

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

В Линуксе такого нет, приложения, которые ставятся из репозиториев дистрибутива – обычно ведут себя скромно и прилично.

Поэтому галка в настройках приложения «Добавить в автозагрузку» - ничего плохого не содержит по своей сути.

А для этого нужно уметь находить связь окна и desktop файла.

Это нужно только тебе! Никакой связи нет и она не нужна! Как и сами desktop файлы ненужны! Линукс прекрасно работает без desktop-файлов. Это «костыли» для некоторых DE, идея которых украдена с винды.

фанатик подгорел, люблю такое)

Это нужно только тебе! Никакой связи нет и она не нужна!

xD

так нужна или не нужна?

Линукс прекрасно работает без desktop-файлов.

Линукс прекрасно работает даже без приложений и без тебя. Линукс - это ядро.

так нужна или не нужна?

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

Для этого нужно знать имя desktop файла, из которого оно запущено.

Зачем ему это знать? Приложение может эталонную копию desktop файла у себя в ресурсах держать и легко создавать в автозагрузке(или на рабочем столе) ярлык в любой момент. И если никто не будет этот файл потом курочить руками, то оно всегда сможет его же и удалить, т.к. знает имя с которым создавало свой файл.

А есть еще проблема затенения метаданных. Обновилось приложение, в систему прилетел новый desktop файл. А в хомяке у пользователя лежит необновлённый, который имеет более высокий приоритет.

Проверяй при запуске файл в фомяке и в /usr/share/applications на соответствие и если не соответствует, то обновляй. Хотя, за такое и по рукам дать можно, ибо нехрен моем хомяке файлы трогать, я мог его сам скорректировать и негоже его затирать.

Апи ядра ОС очевидно фундаментальнее чем апи любых юзерспейсов, а апи графического сервера фундаментальнее чем апи любых приложений к нему, коими являются DE.

Вполне логично, что эти метаданные приложению необходимо бывает ЗНАТЬ, а в ряде случаев еще и УПРАВЛЯТЬ ими. И вот здесь мы приходим к исторически сложившейся жопе.

Эм, нет. Ни одна вменяемая прога не зависит от .desktop файла. Точнее, я вообще ни одной такой проги не видел, .desktop везде это именно DE-шная запускалка и ничто иное. Я допускаю, что какие-то сушасшедшие могли попытаться его использовать в самой проге, но это с их стороны было бы очень плохо.

например, добавить себя в автозагрузку или удалить из автозагрузки. Для этого нужно знать имя desktop файла, из которого оно запущено.

Это делается намного проще: путь к общесистемному файлу зашит в пакете, а автозагрузочный, который в $HOME, просто генерится заново там где надо. Собственно, других вариантов всё равно нет, даже если ты добавишь туда какой-то сложный алгоритм выяснения откуда запущена прога.

1. если desktop файл был внутри пакета deb, то это можно вычислить
2. если приложение само создало ярлык на рабочем столе, как например tor, то никак

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

А в меню «Пуск» (Start Menu), "C:\ProgramData\Microsoft\Windows\Start Menu" кто его создаёт директорию и помещает ярлык?

Так что является.

В общем, ситуация аналогичная, как и с Desktop файлом.

Самому приложению это нахрен не надо

А вот захотела приложенька добавить количество новых сообщений в значок или строку прогресса или еще что-то такое, как она это будет делать?

Как раз .desktop файл это полная аналогия ярлыка Windows.

А скрипт-обёртка в Linux - аналог bat, cmd, ps, vbs скриптов в Windows.

lnk файл, так же как и desktop файл - это понятие графического окружения.

Не путай понятия.

Ну тут разника как я думаю в том, что вместо desktop файлов может быть своя реализация и все будет работать.

десктоп-файл - это часть системы.

То есть это не незаменимая часть системы. У меня например в CDE desktop файлов ну просто нету.

В теме под чуть ли не половиной комментов очень просится этот мем: https://pikabu.ru/story/prosto_ne_ponimaet_2727268

Вот например человек пишет: «это не незаменимая часть системы».

Открою секрет. В опенсорсном дистрибутиве, который поставляется как «мешок утилит» вообще нет «незаменимых частей».

Хочешь запустить другой юзерленд поверх ядра linux? Пожалуйста.

Хочешь запустить ГНУ-тый юзерленд поверх ядра freebsd? Пожалуйста.

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

Хочешь заменить systemd на openrc? Пожалуйста.

Хочешь сделать гибридный контейнер с выборочной эмуляцией, который псевдо-нативно компилирует ARM-овский код на x86 машине? Пожалуйста.

https://planet.kde.org/nicolas-fella-2022-01-11-the-importance-of-window-to-desktop-file-mapping/

Ну да, но это не отменяет того факта, что апи ядра - вещь уважаемая, а вот фантазии гномоделов - нет.

Заводишь key map, где ключ - имя запускаемого файла и хранимое значение – имя файла desktop. Всё.

Тебе слово «произвольное» в моем тексте о чем-то говорит?

Ты точно программист?

Да. Четвертый месяц. А сколько линуксячьих костыльных технологий нужно выучить, чтобы получить сей почетный титул?

эта форма рекомендована [https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/)

Поэтому такой бардак и творится.

Скажи, а в Windows ты можешь узнать по pid процесса или идентификатору окна с какого ярлыка было запущено приложение?

В Windows вся нужная информация идет вместе с процессом.

Здесь - я тебя удивлю. И даже процитирую https://developer-old.gnome.org/libwnck/unstable/WnckApplication.html#wnck-ap... :

Since there is no way to properly find this name, various suboptimal heuristics are used to find it.

То есть даже графический сервер запустивший приложение, не имеет возможности узнать его имя. Ну и бардак.

Смотри, как какая-нибудь Unity DE это делает в коде.

Парсерами и велосипедами.

Некоторые реализации даже содержат в себе вхардкоженный код для оверрайдинга значений в зависимости от имени софта.

Што?

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

Это нормально, не нормально - не иметь общий стабильный механизм для получения минимально необходимой информации о запущенной программе.

Как раз .desktop файл это полная аналогия ярлыка Windows.

Нет. В Windows сия аналогия зовется PIF.

В Windows сия аналогия зовется PIF.

Садись, два. Через неделю пересдашь.

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

Только вот это общение не с приложением, а с DE. Садись, два.

Тебе слово «произвольное» в моем тексте о чем-то говорит?

Я думал, что процесс заполнения key-map очевиден: парсишь все файлы desktop, до каких сможешь дотянутся.

Только вот это общение не с приложением, а с DE. Садись, два.

Это общение ни с приложением, ни с DE. Это дергание *.desktop-файла, чтобы понять какие у программы есть ключи запуска и как они называются.

Если я удалю *.desktop файл - все мои DE не узнают что у Хромиума есть меню «New incognito Window». Это не API, это попытка влезть на территорию API.

Я думал, что процесс заполнения key-map очевиден: парсишь все файлы desktop, до каких сможешь дотянутся.

Я думал ты прочитал название темы. Первое слово.

Садись, два. Через неделю пересдашь.

Открой любой LNK файл и удивишься.

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

Правильный способ – использовать готовое DE а не пыжиться сделать свой велосипед.