LINUX.ORG.RU
ФорумTalks

[freedesktop][.desktop] Почему оно так? (и опять про всякие *step'ы)

 


0

0

Начну с вопроса:
Возможно ли однозначно сопоставить .desktop-файл (используемый для запуска приложения) с открытыми окнами и/или с процессом?
Например, есть firefox.desktop, есть открытое окно этого самого фф, есть процесс 3452.
Так, вот как определить, что процесс 3452 запущен используя firefox.desktop, а открытое окно принадлежит ему.

Как выяснил нормального способа не существует.
Можно только для окна найти процесс.

Для того, чтобы для окна (или процесса) найти .desktop-файл надобны всякие гадания на кофейной гуще (анализ командной строки, сравнение WM_CLASS и названия desktop-файла, везет далеко не всегда).
100% способа нет.

Спрашивается, почему бы просто не писать WM_CLASS в .desktop-файле?
(куда пистаь чтобы это включили в стандарт?)

К чему это я?
Вот посмотрите на DockBarX - замена для панели задач с группировкой + запускалка.
Для того, чтобы создать новую кнопку для запуска приложения необходимо ввести класс окон этого приложения.

AWN/Gnome-Do/.... не просят вводить клас при перетаскивании .desktop-ярлыка на док, так удобнее, но довольно часто эти доки не могут определить, что окна соответствуют уже существующему значку и создают новый (либо вообще не пытаются группировать окна одного приложения).
Получается раздутая панель задач, которая вместо функциональности добавляет трудности.

Т.е. написать нормальную пускалку - проблема.
(Или есть ответ на первый вопрос?)


Теперь про *step'ы.
GNUStep'овские проги сами рисуют себе иконку. Отпадает проблема группировки, с запускалкой тоже нет проблем.
Плюс к этому при нажатии на иконку происходит действие (в случае с gnustep'ом показывается меню, но это не важно), да иконка может менятся при необходимости.
Хорошая же концепция. Чего другие так не стали делать?
Тогда панель задач была бы просто контейнером.

Ну, это так, мячты, обсудить хочется первую часть поста.

★★★★★

>AWN/Gnome-Do/.... не просят вводить клас при перетаскивании .desktop-ярлыка на док, так удобнее, но довольно часто эти доки не могут определить, что окна соответствуют уже существующему значку и создают новый (либо вообще не пытаются группировать окна одного приложения).

Вот для Gnome-Do я такого ни разу не видел, можно пример проги, для которой это происходит?

kss ★★★★★
()
Ответ на: комментарий от kss

Раньше такое было часто, видимо они поработали в этом плане.
Сейчас попробовал несколько прог - все нормально.

НО! Таки проги могут быть!
Бегло просмотрел часть сорцов от Gnome-Do. Там есть обработчики конкретных случаев, т.е., с какими прогами как поступать, также есть префиксы для разбора командных строк и т.д.
Т.е. решение рабочее для известных прог, благодаря тому, что создатели Gnome-Do все проверили и составили списки.

Поэтому вопрос остается открытым.

ls-h ★★★★★
() автор топика
Ответ на: комментарий от kss

Нашел. GNUStep приложения оно не различает и лепит их все на одну иконку.
Ну, это мелочь.
Но проблема в том, что делается это все средствами всяких списков в Do, т.е. нет универсально механизма.

ls-h ★★★★★
() автор топика

У приложения может быть несколько окон с разными WM_CLASS. Единственный честный способ - у окна узнать запускалку, потом с выпученными глазами бегать искать соотв. десктоп файл. Кстати, в общем случае и тут может случиться облом - если на одну екзешку несколько десктоп-файлов с разными опциями командной строки;)

svu ★★★★★
()

В макоси подобная функциональность достигается жестокими ограничениями и особенностями.

Два экземпляра одного приложения запустить нельзя (хаки не в счет, они все-равно отдельную иконку в доке создают).

90% приложений представляют собой один каталог /Application/%APP_NAME%.app, т.е можно однозначно определить как приложение запускали.

Как таковые "ярлыки" в макоси тоже неиспользуются. Есть Бог Отец, Бог Джопс и.. , тьфу.. есть каталог с .app'ами и док-пускалка, все однозначно друг-другу сопоставимо.

mono ★★★★★
()
Ответ на: комментарий от ls-h

я к тому, что работать это все будет на практике, только если жестко прибить гвоздями к функционалу типа *step, т.е выкинуть всякие .Desktop-фейлы.. оставить какой-нибудь каталог приложений и управлялку ими в док-стиле.

mono ★★★★★
()
Ответ на: комментарий от ls-h

Я отучился говорить за весь фрешмит.

svu ★★★★★
()
Ответ на: комментарий от ls-h

>>У приложения может быть несколько окон с разными WM_CLASS
>такие есть или это в теории?

Гимп, если я ничего не путаю.

Alsvartr ★★★★★
()

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

prorok2k
()
Ответ на: комментарий от Alsvartr

>Гимп, если я ничего не путаю.

У гимпа один WM_CLASS = "gimp", "Gimp", а меняются заголовки. Нет возможности поставить xmms, вот он менял класс для каждого окошка.


А вообще в этом отношении рулит WindowMaker, последователь GNUStep. Вроде как он умеет с параметрами окна обращатся как надо. Давно не работал с обоими, может что-то путаю. Но GNUStep по своей архитектуре UI отстал, т.к. перестали развивать то направление дизайна.

gh0stwizard ★★★★★
()
Ответ на: комментарий от prorok2k

> Если мы делаем свою запускалку, то какие проблемы?
Проблема в том, что из этой запускалки можно запустить xterm. А из него - что угодно.

svu ★★★★★
()
Ответ на: комментарий от prorok2k

И польза от запускалки если она не будет работать (определять что приложение запущено) при старте проги например из меню?

ls-h ★★★★★
() автор топика
Ответ на: комментарий от gh0stwizard

WMaker у меня стоит. Не сильно то он и рулит. Иконки как привило находит страшные, когда есть нормальные, создать нормальный лаунчер тоже не всегда удается.
Иногда при перетаскивании значка приложения снизу (из области для минимизации) в док появляется окошко для ввода параметров.

ls-h ★★★★★
() автор топика
Ответ на: комментарий от mono

Я вижу два решения:

Первое, наиболее предпочтительное, чтобы приложения сами создавали себе кнопки/иконки. При этом нет необходимости во всяких .app для приложений, они могут оставаться размазанными как сейчас (bin,lib,share,...). Просто нужен стандарт на уровне freedesktop, что при запуске первым делом приложение рисует себе кнопку, потом уже открывает окна.
Так можно избавится от многих костылей, например сейчас во всяких доках (awn/gnome-do/cairo) делают всякие кнопки для управления разными приложениями (например, кнопки "воспроизвести", "пауза",... для rhytmbox'а), т.е. пытаются идти по пути макоси и всяких степов, но только очень костыльным путем (используя d-bus и т.п.).
Если приложение будет само рисовать себе кнопку, то оно может нарисовать там все что угодно, хоть opengl'ное что-нибудь, можно сделать какое надо меню, отображать разные прогрессы и т.д.
Панель задач в этом случае - обычный контейнер.

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

Второе решение более простое и более быстрое. Первое - лучше.
И никакого жесткого прибивания не будет свободы остается столько сколько и было.

ls-h ★★★★★
() автор топика

Куда писать предложения и пожелания для freedesktop?

Может вместе напишем?

ls-h ★★★★★
() автор топика
Ответ на: комментарий от Gorthauer

Плохой переносимостю куда? Есть же проги которые под лин, вин, мак...

Какие велосипеды?
Написать стандарт какие свойства должны быть у окна иконки/кнопки чтобы ее съела панель задач.
Написать рекомендации, что у кнопки должен быть список окон и вменяемая кртинка.
А дальше пусть разработчики делают что им надо.
Сделать чтобы приложение создавало еще одно окно я думаю не сложно.

ls-h ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.