История изменений

Как основатель проекта и один из разработчиков этого самого докбарХэ хочу сказать следующее:

Почему не любят? Любят! Я вот люблю. И от любви-с, так сказать, написал dockbar. Потом присоединился программист из Финляндии, создал новую ветку с некоторыми фишками и добавил букву хэ. А потом меня обуяла вселенская печаль и я забил на дальнейшее развитие. Он некоторое время писал, потом, вроде, тоже забил. Проистекла печаль из следующего:
1. Линукс не готов для десктопа дока и всё делается через анус
2. Все кладут на стандарты большой /dev/random

Поясню вышеописанное. В Макоси написать док просто, в винде - тоже. Хотя и там и там они менее функциональные, чем мое поделие /жутко гордясь прыгаю на стуле/ и многие другие аналоги. В линуксе надо вагон костылей и подпорок. Вот у нас открыто несколько окон, их можно сворачивать, разворачивать и т.п. И это единственное, в чем можно быть уверенным. Принадлежат ли они одному приложению? Что это за приложение? Как запустить еще экземпляр? Тут начинаются танцы с бубном. У окна есть атрибуты, типа WM_CLASS, WM_NAME (ЕМНИП, такие атрибуты называются атомами), но там может быть написано не то, что ожидаешь. Например (на момент моего участия в проекте это было так), все приложения OpenOffice'а имели одинаковый класс, поэтому Writer, Calc и прочие приходилось отличать друг от друга по разным признакам. И это еще не самый гемор. У некоторых приложений там нету ничего, у некоторых что-то общее для тулкита. Потому, что авторы забили. Поэтому приходилось идти дальше и смотреть, чего за процесс открыл это окно. Но геморрой на этом не заканчивается. Ну вот процесс, пусть даже WM_CLASS заполнен адекватно. Но, что это за приложение с т.з. пользователя? Надо найти нормальное название, правильную иконку. Если это gnome-terminal какой-нибудь, то всё круто и просто. А если это приложение на скриптовом языке, то надо разобрать командную строку, потому что имя процесса будет именем интерпретатора и ни о чем не скажет. В командной строке, к примеру, могут быть опции к интерпретатору перед именем файла скрипта, что тоже хлопотно. Ну ладно, бинго, есть имя исполняемого файла или скрипта, теперь надо найти от него .desktop-файл, чтобы достать из него имя приложения и иконку и узнать команду запуска. Тут опять облом, т.к. в нужном .desktop-файле в поле exec написано wrapper.sh и хрен это сопоставишь с процессом mysupernotepad или с WM_CLASS=Gtk-window. Подобных косяков там еще очень много.
Вообще, есть спецификация на .desktop-файлы, которая гласит что есть поле StartupWMClass (ЕМНИП, давно это было), а приложение, когда оно запустилось, должно создать как минимум одно окно с WM_CLASS=StartupWMClass и всё будет чики-пуки. Но поле это необязательно. Не знаю, как сейчас, опять же давно не смотрел, но на момент написания дока все на это поле забивали и всё это соответствовало спецификации только для пары приложений. Я даже писал в freedesktop.org с предложением сделать StartupWMClass обязательной штукой. Они ответили предложением забить.
В результате всего этого внутрях dockbar/dockbarx большое шаманство с сопоставлением всех возможных атрибутов (WM_CLASS-а, имени процесса, командной строки, названия .desktop-файла, многих полей из .desktop-файла и т.п.) друг другу, с надеждой «авось совпадет», плюс костыли для известных проблемных приложений.
Знаю, что внутрях AWN примерно такая же шляпа. Исходники других доков не читал. А для unity есть целый набор библиотек с демоном и общением по dbus, с большушей кучей костылей и подпорок. ЕМНИП, называется BAMF, можно найти на launchpad.net. И это всё вместо того, чтобы соблюдать спецификации.
Костылестроение у меня вызывает депрессию, рвотный рефлекс и клшмары по ночам, поэтому я забил на это всё.
В винде: окно -> ехе-шник -> там есть иконка и название. В макоси, наверное, примерно так же, все написано в бандле .app.

Как основатель проекта и один из разработчиков этого самого докбарХэ хочу сказать следующее:

Почему не любят? Любят! Я вот люблю. И от любви-с, так сказать, написал dockbar. Потом присоединился программист из Финляндии, создал новую ветку с некоторыми фишками и добавил букву хэ. А потом меня обуяла вселенская печаль и я забил на дальнейшее развитие. Он некоторое время писал, потом, вроде, тоже забил. Проистекла печаль из следующего:
1. Линукс не готов для десктопа дока и всё делается через анус
2. Все кладут на стандарты большой /dev/random

Поясню вышеописанное. В Макоси написать док просто, в винде - тоже. Хотя и там и там они менее функциональные, чем мое поделие /жутко гордясь прыгаю на стуле/ и многие другие аналоги. В линуксе надо вагон костылей и подпорок. Вот у нас открыто несколько окон, их можно сворачивать, разворачивать и т.п. И это единственное, в чем можно быть уверенным. Принадлежат ли они одному приложению? Что это за приложение? Как запустить еще экземпляр? Тут начинаются танцы с бубном. У окна есть атрибуты, типа WM_CLASS, WM_NAME (ЕМНИП, такие атрибуты называются атомами), но там может быть написано не то, что ожидаешь. Например (на момент моего участия в проекте это было так), все приложения OpenOffice'а имели одинаковый класс, поэтому Writer, Calc и прочие приходилось отличать друг от друга по разным признакам. И это еще не самый гемор. У некоторых приложений там нету ничего, у некоторых что-то общее для тулкита. Потому, что авторы забили. Поэтому приходилось идти дальше и смотреть, чего за процесс открыл это окно. Но геморрой на этом не заканчивается. Ну вот процесс, пусть даже WM_CLASS заполнен адекватно. Но, что это за приложение с т.з. пользователя? Надо найти нормальное название, правильную иконку. Если это gnome-terminal какой-нибудь, то всё круто и просто. А если это приложение на скриптовом языке, то надо разобрать командную строку, потому что имя процесса будет именем интерпретатора и ни о чем не скажет. В командной строке, к примеру, могут быть опции к интерпретатору перед именем файла скрипта, что тоже хлопотно. Ну ладно, бинго, есть имя исполняемого файла или скрипта, теперь надо найти от него .desktop-файл, чтобы достать из него имя приложения и иконку и узнать команду запуска. Тут опять облом, т.к. в нужном .desktop-файле в поле exec написано wrapper.sh и хрен это сопоставишь с процессом mysupernotepad или с WM_CLASS=Gtk-window. Подобных косяков там еще очень много.
Вообще, есть спецификация на .desktop-файлы, которая гласит что есть поле StartupWMClass (ЕМНИП, давно это было), а приложение, когда оно запустилось, должно создать как минимум одно окно с WM_CLASS=StartupWMClass и всё будет чики-пуки. Но поле это необязательно. Не знаю, как сейчас, опять же давно не смотрел, но на момент написания дока все на это поле забивали и всё это соответствовало спецификации только для пары приложений. Я даже писал в freedesktop.org с предложением сделать StartupWMClass обязательной штукой. Они ответили предложением забить.
В результате всего этого внутрях dockbar/dockbarx большое шаманство с сопоставлением всех возможных атрибутов (WM_CLASS-а, имени процесса, командной строки, названия .desktop-файла, многих полей из .desktop-файла и т.п.) друг другу, с надеждой «авось совпадет», плюс костыли для известных проблемных приложений.
Знаю, что внутрях AWN примерно такая же шляпа. Исходники других доков не читал. А для unity есть целый набор библиотек с демоном и общением по dbus, с большушей кучей костылей и подпорок. ЕМНИП, называется BAMF, можно найти на launchpad.net. И это всё вместо того, чтобы соблюдать спецификации.
Вот потому я и опечалился и перестал писать.
В винде: окно -> ехе-шник -> там есть иконка и название. В макоси, наверное, примерно так же, все написано в бандле .app.