[freedesktop] Хочу изменить спецификацию (нужна поддержка)

да, у меня есть вариант - wmii

Мысль приятная, но мне кажется не найдется достаточных оснований делать StartupWMClass обязательным. Что можно сделать - слать баги в приложения, с патчами. ВОЗМОЖНО, если удастся набрать некую массу таких приложений, будет смысл поднять вопрос об обязательности еще раз.

И еще хорошо бы попробовать заслать казачка - придумать для имеющихся массовых десктопов (оконных менеджеров) красивые способы использовать эту проперть...

(идя далее по треду в xdg) впрочем, если убунту займется причесыванием приложений в эту сторону - может, дело и пойдет...

Не читал, но осуждаю:

1. Как быть с консольными приложениями? Или приложениями, которые используют скриптовые обертки над тулкитами?

2. Как быть с тем, что у приложения может быть несколько состояний (нормальное окно + окно администрирования) с РАЗНЫМИ иконками/названиями, но само приложение в виде одного бинарника?

Вариант: при запуске из десктоп-файла читать проперти и привязывать их к ПИДу приложения, хотя это тоже криво.

Который раз встречаю обсуждение об этом, до сих пор не пойму зачем оно надо.

это исключительная проблема Gnome, не надо её тащить на freedesktop, вон в кедах надстроили трей над общепринятым и ничего никого менять не просили

>1. Как быть с консольными приложениями?
Консольные приложения запускаются в терминале. Откроется окно терминала, WM_CLASS которого будет типа terminal:Terminal.
Система определит, что запущен терминал.
Что запущено в нем - не будет определено.

Если посмотреть в меню, много ли там прог, которые запускаются в терминале?
У себя нашел htop.
Смысл связи приложения и .desktop-файла в том, чтобы найти нормальную иконку, локализованное имя, и т.д. (см. первый пост).
Актуально ли это для консольных программ?
Если очень хочется, то можно немного переделать терминал, чтобы он в WM_CLASS писал имя_проги:Terminal, вместо terminal:Terminal.
Т.е. решение есть.

>Или приложениями, которые используют скриптовые обертки над тулкитами?
В чем проблема? Тулкиты позволяют задавать имя приложения и выставляют WM_CLASS для окон.
Если приложение написано на скриптовом языке это не значит, что оно будет без имени.

>2. Как быть с тем, что у приложения может быть несколько состояний...
Нормально быть. Приложение может выставлять разные WM_CLASS'ы.
Например WM_CLASS'ы приложений OpenOffice'а: writer:OpenOffice.org, impress:OpenOffice.org и т.д. (У приложений OOo бинарник один)


>Вариант: при запуске из десктоп-файла читать проперти и привязывать их к ПИДу приложения, хотя это тоже криво.
Тогда будет нужна единая система запуска, т.к. приложение может быть запущено не только из меню. Одни приложения могут запускать другие, также возможен запуск из терминала.
Придется переписать все приложения.

Проблема общая. В кде все точно также в этом плане.
К тому же в гноме могут запускаться проги из кед и наоборот, кроме того есть приложения вне гнома и кед.

> Консольные приложения запускаются в терминале.

В терминале могут запускать и графические приложения тоже. Я K3B всегда из терминала запускаю. Чей .desktop должен опознаваться? Терминала? А если и терминальная программа запущена не из .desktop-файла, а комбинацией клавиш "Win+~"?

>В терминале могут запускать и графические приложения тоже.
Если запускать из терминала графическую прогу, то ее .desktop и опознается.
Все очень просто. У окон K3B будет свойство WM_CLASS.
Программа (док, панель задач, ....) прочитает WM_CLASS, сравнит его со списком WM_CLASS:.desktop-файл и, таким образом, найдет .desktop от K3B.

Еще раз суть обращения в freedesktop:
Изменить спеки .desktop файлов так, чтобы они содержали WM_CLASS запускаемого приложения.
Не важно как оно будут запущено (меню, терминал, ....).

У любого окна есть свойство WM_CLASS.
У всех окон одного приложения WM_CLASS'ы одинаковы.
Среди приложений WM_CLASS'ы уникальны.
Поэтому не составляет труда зная WM_CLASS найти .desktop-файл от приложения.
Нужно только, чтобы .desktop-файлы содержали ключ WM_CLASS.
Просмотрите содержимое нескольких .desktop'ов. Вот, туда добавится еще 1 ключ - WM_CLASS.

Например (ярлык для firefox'а):
Name=Firefox browser
Name[ru]=Браузер Firefox
Exec=/usr/bin/firefox
WM_CLASS=Firefox
- это простой случай. Для многих прог невозможно найти чтолибо равное WM_CLASS'у в .desktop-файлах, либо требуется анали содержимого.

//off


>"ЛОР-овцы"

Гыгы.

а можно не трахать себе мозг и пользовать Enlightenment-DR17. там всё, что описано как проблема, проблемой не является. т.е.:

- каждое приложение может иметь свою собственную (на выбор Лузера) иконку и показывать его в меню
- легко редактировать соответствующие "*.desktop" файлы в "~/.local/share/applications" с навигацией EFM-ом и тупым D'n'D в тот же SciTE
- "запускалка" (любая) делается на раз

это к тому, что всякие идеи типа "сделать обязательным ключ StartupWMClass" или ещё какое "ЦУ сверху" на уже написанный и работающий софт - занятие неблагодарное. а если у "разработчиков Gnome-Shell" проблемы - так никто не мешает взглянуть на реализацию в том же Enlightenment-DR17 и сделать нечто похожее (imho уж сколько оттуда ушло идей в четвёртые кеды...)

>>1. Как быть с консольными приложениями?

>Консольные приложения запускаются в терминале. Откроется окно терминала, WM_CLASS которого будет типа terminal:Terminal.

И нарисует иконку от терминала? Ненене, я так не хочу!

>Если посмотреть в меню, много ли там прог, которые запускаются в терминале?

Много, это же люникс. Я бы не отказался видеть в таскбаре иконки mc / iptraf / modplugplay / mplayer, хотя все они консольные (окна у мплеера не всегда есть)

>Актуально ли это для консольных программ?

да

>Если очень хочется, то можно немного переделать терминал, чтобы он в WM_CLASS писал имя_проги:Terminal, вместо terminal:Terminal. Т.е. решение есть.

Костыльное решение, требующее переработки 100500 приложений.

>В чем проблема? Тулкиты позволяют задавать имя приложения и выставляют WM_CLASS для окон.

Тулкиты то позволяют, вот только как часто оно из скриптовых языков присваивается?

Вот тут я запустил Frozen Bubbles, у которого класс sdl_app... Есть мнение, что это далеко не одно приложение с таким классом...

> Среди приложений WM_CLASS'ы уникальны.

Нет, как видим...

Или, у меня в gaim у всех окон одинаковый класс, но иконки то разные...

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

Читал на planet.kde.org пост про реализацию кнопки-запускалки которая будет знать что приложение запущено (где-то с недели две назад). Соответственно в кде в реализации такого стандарта были бы заинтересованы.

>Нет, как видим...
Ну, какбы должно. Разработчик приложения не читает стандарты.
Я могу написать прложение и сделать у него WM_CLASS="OpenOffice.org".
Это не говорит о том, что стандарты плохие, а только о том, лучше их соблюдать.
Поставил для интереса бабл - WM_CLASS = 'perl', т.к. игрушка написана на перле.

>Или, у меня в gaim у всех окон одинаковый класс, но иконки то разные...
Мы говорим про приложения а не про окна.

>А что мешает взять путь до бинарника, найти его в списке desktop-файлов и прочитать все необходимое?
Так. Еще раз. У нас есть панель задач/док/запускалка/... (нужное подчеркнуть).
Открывается окно терминала. Нам нужна возможность сделать ярлык для терминала и возможность определить, что терминал уже запущен (чтобы не лепить кучу кнопок на панели задач (для ярлыка и для запущенного), а использовать кнопку/иконку от ярлыка, например, подсветив ее).
Так вот есть окно. Что дальше?
Ну, узнать pid процесса из св-в окна. По нему прочитать коммандную строку из /proc/<pid>/cmdline.
Потом найти такуюже строку в списке desktop файлов.
Если Вы думаете, что это решение, то попробуйте написать dock для линукса.
Такой метод будет работать очень редко (с терминалом и еще парой прог), т.к. с командной строкой не все так просто:
- надо парсить параметры, т.к. 1 бинарник может быть разными "приложениями" (см. OOo)
- cmdline и строчка из desktop'а могут сильно отличаться
- разные префиксы для интерпретаторов (python, mono, java,....)
перечислять можно долго.
Попробуйте написать простой скрип, который бы находил .desktop файл имея только свойства открытого окна.


>И нарисует иконку от терминала? Ненене, я так не хочу!
Вы это специально придумали, чтобы показать на изъян?
Терминал - отдельное приложение, вне зависимости от того, что в нем запущено.
В одном окне терминала в разные моменты времени могут работать разные консольные проги.
Создавать для ls, cat, emacs, vi, .... и вообще всего, что есть исполняемого в системе?
Ну, хорошо, есть ярлык для mc, Вы же можете запустить в том же окне emacs. Что тогда делать?
А с графическими прогами так нельзя. Невозможно запустить nautilus в gedit :)

> Читал на planet.kde.org пост про реализацию кнопки-запускалки которая будет....
Поделитесь ссылкой!

http://www.kdedevelopers.org/node/4038

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

> Ну, какбы должно. Разработчик приложения не читает стандарты.

Welcode to real world!

> Поставил для интереса бабл - WM_CLASS = 'perl', т.к. игрушка написана на перле.

Еще интереснее, класс окна зависит от версии... Причем возможно версии библиотек/прослоек...

> - надо парсить параметры, т.к. 1 бинарник может быть разными "приложениями" (см. OOo)

Об этом я писал, тут все вилы и лежат...

> Попробуйте написать простой скрип, который бы находил .desktop файл имея только свойства открытого окна.

А в чем проблема?

> Вы это специально придумали, чтобы показать на изъян?

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

> Создавать для ls, cat, emacs, vi, .... и вообще всего, что есть исполняемого в системе?

Зачем же? Достаточно для всякого долгоиграющего, типа mc / iptraf / *top

> Ну, хорошо, есть ярлык для mc, Вы же можете запустить в том же окне emacs. Что тогда делать?

Можно нарисовать 2 иконки на таскбаре :)

> А с графическими прогами так нельзя. Невозможно запустить nautilus в gedit :)

Дело времени... Вот в кедах можно благодаря KParts, в гноме есть похожая штука - бонобо, наверняка тоже что-то такое предусмотрено :)

>Welcode to real world!
И что? Давайте вообще не соблюдать стандарты. Давайте напишем web-браузер, чтобы работал из под рута.

>Можно нарисовать 2 иконки на таскбаре :)
Т.е. панель задач должна отследить что пользователь поп mc запустил emacs и создать 2ю иконку?
Смысл 2х иконок? Закрыть mc, не закрыв emacs не получится.

Сходите в винду. Создайте ярлык напрмер для powershell (альтернативная командная оболочка), создайте ярлык для какой-либо виндовой консольной проги (например defrag) с другой иконкой.
Запустите 1й ярлык (появится 1ая иконка и кнопка на пз).
В окне powershell'а наберите defrag, нажмите Enter.
Как по Вашему иконка на пз должна измениться?



Говоря ЛОРовским языком - "Толсто!"

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

Повершелла у меня нет, да и загружать винду лениво. Не меняется? Ну и фиг с ней (вообще, насколько я помню, консольное приложение может найти WHND своего окна и поменять себе иконку). Я вообще проблем не вижу, до сего дня для меня такой проблемы небыло.

Да, с "Толсто" я погорячился.
Ну а проблему я нашел когда стал писать свой док для линукса.
Нормального и всегда (или хотя бы почти) работающего способа сделать лаунчер я так и не нашел.

А у WM спросить никак нельзя?

Я ничего такого не нашел.
Думаю, что нельзя.
WM'у то надо проделать туже работу, с теми же проблемами.

> Который раз встречаю обсуждение об этом, до сих пор не пойму зачем оно надо.

Чтобы сделать док как в маке или панельку как в севене.

Жуть какая :}

> Жуть какая :}

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

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

Прописывать в .desktop это костыль, ибо запускать можно далеко не только оттуда.

> Прописывать в .desktop это костыль, ибо запускать можно далеко не только оттуда
!!!! Научите, как запускать из .desktop файла!!!!

> Прописывать в .desktop это костыль, ибо запускать можно далеко не только оттуда.

Требуется способ связать WMCLASS с .desktop файлом. Тот же dockbarx (апплет для гномпанели, похожий на переключалку/запускалку приложений севена) при драгндропе лаунчера на него спрашивает WMCLASS. Иногда он его угадывает, иногда нет.

> Требуется способ связать WMCLASS с .desktop файлом.

${WMCLASS}.desktop

>вон в кедах надстроили трей над общепринятым и ничего никого менять не просили

...

>а можно не трахать себе мозг и пользовать Enlightenment-DR17

...

Что эти люди забыли в Linux?

Спокойно, сву, всё под контролем :}

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

> Напишем ещё костылей для ещё более медленной работы?

NextStepы и PalmOSы с таким же подходом работали по сути на калькуляторах (по современным меркам).

А в наших линуксах отключабельно всё.

Вот бы ещё kdepim от mysql-server отключить :}

Наверное это недостаток кдепима, а не наших линуксов.

Вот сделают тут тоже таким топорным способом и тогда посмотрим, что чей недостаток :}

Пипец!

Почитайте тему, сходите по ссылкам.
Для тех кто в танке:
При запуске дока он читает .desktop файлы, которые находит и делает словарь (ассоциативный список) вида имя_класса|имя_.desktop_файла.
При открытии окошка у него читается WM_CLASS и сравнивается со списком.
При перетаскивании на док .desktop'а из него читается WM_CLASS.
Приложение может быть запущено _как угодно_.

Ну, почти.

Самый правильный путь - сделать так, чтобы приложения сами рисовали себе иконку в панели задач (например встраивание через XEmbed).
Я об этом пишу уже давно и не только тут, но и на других сайтах тоже.
http://www.linux.org.ru/view-message.jsp?msgid=3765372
Народ читает, говорит что это макофилия, напоминает про Джобса и какой то зонд, забывая, что док придумали не эппл с Джобсом.

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

Пипец!

Почитайте тему. Оно не нужно.

Fixed.

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

Next (Open) Step?

> Оно не нужно.

Трей и панель задач это Windows 95 style. Мне не нравится.

So? Выключи. В моём посте не было никакого утверждения на тему «как в макосе/винде/етц».

> Выключи.

Есть приложения, который жуть как хотят трей. Да и альтернатив особо нет.

> В моём посте не было никакого утверждения на тему «как в макосе/винде/етц».

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

По мне так это демагогия, мол, мы назовём A B и сделает вид, что это новая супермегафича.

>По мне так это демагогия, мол, мы назовём A B и сделает вид, что это новая супермегафича.
Неа. Принципиальная разница.
А - сторонние приложение рисует кнопки на панели для окон
Б - приложение само рисует, что ему надо
Во втором случае получаем много вкусных плюшек:
http://www.linux.org.ru/view-message.jsp?msgid=3765372

>А - сторонние приложение рисует кнопки на панели для окон
>Б - приложение само рисует, что ему надо

Быть может А рисует такие что-то, что предоставляет саму панель задач? По мне, так это куда лучше, чем сбрасывать всё на приложение, которое, к тому же, может и вообще повиснуть или задуматься над IO, например.

> - трудно найти нормальную иконку

Иконка выставляется приложением для WM, другое дело, что она 16x16, необходим механизм для трансляции иконок на любые размеры — по моему, кдуа более интересная и актуальная задача, учитывая, что масштабирование иконок требуется не только для WM.

Кто сказал «векторные иконки» — возьми пирожок.

> - трудно найти локализованное имя приложения

А оно вообще надо, если есть класс окна? Я не уверен, что WM_Class необходимо прописывать в desktop файле, если он и так считывается через WM.

> - трудно сделать запускалку/запустить экземпляр приложения

Да, трудно.