LINUX.ORG.RU
ФорумTalks

Всё о зоопарке треев

 , , ,


7

2

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

  • XEmbed-трей (legacy трей):
    Самый первый стандарт трея в UNIX-системах, основан на технологии встраивания в X11. Великая суть: приложение создаёт окно-значок и встраивает в нужную область, просто и сердито.

    Недостатки:
    • Контролировать значок может только само приложение;
    • Не учитывается, что областей трея может быть несколько (на нескольких мониторах);
    • Привязано к X Window System.
    Достоинства:
    • Поддерживается почти везде (кроме Unity и WingPanel (Pantheon));
    • Поддерживают почти все приложения.
    Не самый плохой стандарт, вполне можно считать чем-то вроде UNIX-way, но сейчас как-то отжило своё (не UNIX-way, а XEmbed-трей).

  • SNI-трей (org.freedesktop.StatusNotifierItem):
    Стандарт, впервые представленный в KDE SC 4.4 для решения проблем с XEmbed-треем.
    Взаимодействие приложения с областью трея происходит через dbus, при этом сам значок рисуется областью трея, и при желании область может значок заменять на другой и т.д. Например, в KDE сейчас стандартные приложения типа KMix в трее имеют белые значки, которые делаются на уровне Plasma, а не на уровне самих приложений.
    Хоть StatusNotifierItem и был представлен проектом KDE, наибольшую известность получил в Ubuntu, ибо… в KDE особо не видно разницы :-).
    В свою очередь, в Ubuntu 10.04 были продемонстрированы библиотека libappindicator и ayatana-индикатор indicator-application, которые и реализуют SNI-трей. Собственно, в Ubuntu стал известен не столько StatusNotifierItem/appindicator, сколько сами по себе ayatana-индикаторы, но разработчики приложений таки опираются именно на appindicator.
    Также в Ubuntu есть плагин к трею Qt4 sni-qt, который все Qt4-приложения переводит на SNI-трей, но главная проблема — нужен патч kubuntu_14_systemtrayicon.diff, который так и не попал в upstream Qt4 (в Qt5 таки попал, но сам sni-qt ещё не адаптирован для него).

    Недостатки:
    • Меньшая поддержка, нежели у XEmbed-трея;
    • Меньшая поддержка среди приложений, что, впрочем, сильно улучшается со временем из-за того, что Unity не поддерживает XEmbed-трей.
    Достоинства:
    • Стандарт freedesktop.org;
    • Поддерживается Unity, MATE, Xfce (через indicator-application);
    • Поддерживается WingPanel, Cairo-Dock;
    • Поддерживается GNOME Shell (через расширение, если оно не отвалилось, опять);
    • Не привязано к какому-либо графическому серверу (да и что может помешать приложению из XWayland по dbus слать значок к области трея в Wayland :3?);
    • Гибкость и масштабируемость (отдельно учитывать в стандарте многомониторные конфигурации даже не нужно, всё отлично работает само по себе);
    • Поведение значка определяется самой областью трея.
    Можно сказать, это и есть идеальный трей, стандарт, на который и следует опираться, если не хочется оказаться за бортом (хотя бы вместе с X.Org'ом). Тем более, libappindicator вполне умеет рисовать и XEmbed-значки, если нет области SNI-трея.

  • Ayatana-индикаторы:
    Одновременно с indicator-application в Ubuntu 10.04 были представлены и сами индикаторы в рамках проекта Ayatana.
    Сказать — зачем, как-то особо не получается, все индикаторы (indicator-sound, indicator-bluetooth и т.д., да даже indicator-appmenu) вполне можно было оформить и в виде StatusNotifierItem.
    Большинство компиляций индикаторов, кстати говоря, даже содержат в большей степени appindicator'ы, нежели ayatana-индикаторы, ведь создаватели компиляций всё равно разницы не видят.

    Недостатки:
    • Не так и много дистрибутивов внесли индикаторы в свои репозитории (в openSUSE их нет, в Debian они есть);
    • Больше похожи на прослойку между Unity, MATE, Xfce и appindicator; в общем, не нужны;
    • Индикаторы зависят от Gtk3 или Gtk2 (причём, не все индикаторы имеют поддержку Gtk2; например, indicator-appmenu не имеет);
    Достоинства:
    • Поддерживаются Unity, MATE (через официальный mate-indicator-applet), Xfce (через xfce4-indicator-plugin);
    • Само собой, гибкость на уровне SNI-трея;
    • Привязки к графическому серверу также нет (ayatana-индикаторы, скоро на всех Mir'ах страны!).
    Малонужная штука, но из-за того, что indicator-applet (который и был форкнут в mate-indicator-applet) и xfce4-indicator-plugin были написаны в рамках Ubuntu… в общем, если хочется SNI/appindicator на MATE и Xfce (а кто его не хочет :3?), то и ayatana-индикаторы тоже нужны.

Хотелось бы такую же классную раскадровку о целях и применениях трея. У меня пока дальше индикаторов и редко используемых переключателей мысли не идут. А когда говорят про «свернуть окошко в трей», хочется таких потыкать носом в NEXTStep/OpenStep.

leonidko ★★★ ()

В общем, одно устаревшее нужно и два свистопердельных ненужно. ОК.

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

В общем, одно устаревшее нужно и два свистопердельных ненужно. ОК.

Прочитай ещё раз или иди учить уроки на понедельник.

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

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

Darth_Revan ★★★★★ ()

Не учитывается, что областей трея может быть несколько (на нескольких мониторах);

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

x3al ★★★★★ ()

У меня нуб-вопрос. Я когда подключаю второй монитор не вижу трея на нём. Использую fluxbox. Моник подрубаю как-то так: xrandr --output VGA1 --primary --auto

Кстати, что такое primary? У меня по-прежнему окна по-дефолту всплывают на ноуте :(.

true_admin ★★★★★ ()

*ищет кнопку Like*

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

Я когда подключаю второй монитор не вижу трея на нём

Может быть только одна область XEmbed-трея, значки будут появляться на той области, которая появилась первой.

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

psi, pidgin

Хоть Psi и не умеет, но хотя концептуально indicator-messages вполне заменяет отдельные значки для IM.

Darth_Revan ★★★★★ ()

Например, в KDE сейчас стандартные приложения типа KMix в трее имеют белые значки, которые делаются на уровне Plasma, а не на уровне самих приложений.

И выглядят как говно в светлых темах :}

Deleted ()
Ответ на: комментарий от Darth_Revan

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

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

А, я подумал, что под индикатором ты имеешь в виду исключительно вещи типа индикаторов раскладки, звука и т.д.

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

Это хорошо, не будешь больше пороть чушь про «Расширения гнома — это трей»

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

Это хорошо, не будешь больше пороть чушь про «Расширения гнома — это трей»

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

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

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

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

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 4)
Ответ на: комментарий от Darth_Revan

Это конечно тоже. Просто для приложений вызываемых редко, но нужных, типа IM и т.п., я использую отдельный стол.

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

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

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

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

Darth_Revan ★★★★★ ()
Последнее исправление: Darth_Revan (всего исправлений: 1)
Ответ на: комментарий от Darth_Revan

Меню — отдельное иксовое окно же. Технически им не так сложно управлять отдельно от самой иконки.

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

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

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

Они просто хотели избавиться от XEmbed-трея

Вот и я об этом.

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

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

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

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

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

Они просто хотели избавиться от XEmbed-трея

Вот и я об этом

Цели их вполне понятны. Пестрящие иконки в XEmbed-трее довольно плохо вписываются практически в любой дизайн, а сделать с этим by design ничего нельзя. Ну и, само собой, Wayland.

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

Тоже неверно. Они просто хотели избавиться от XEmbed-трея

Это ложь, гноморазрабы должны были избавиться от XEmbed-трея путём поддержки SNI-трея. А пока что получается, что убунтовцы действительно хотят избавиться от старья (и отсутствием поддержки его в Unity вынуждают разработчиков приложений и библиотек шевелиться), а гномеры как обычно выкидывают фичи под левыми предлогами.

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

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

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

quiet_readonly ★★★★ ()

Важная поправка: WingPanel (Pantheon) поддерживает не appindicator непосредственно, а Ayatana-индикаторы.

Darth_Revan ★★★★★ ()

Лучше объясни, что из всего этого заработает в kubuntu?

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

Ага, вот и сижу, меняю руками… ибо всем пофиг.

Deleted ()
Ответ на: комментарий от Darth_Revan

XEmbed-трей и SNI-трей

Ну вот у Psi в Unity контекстное меню значка совсем другое, нежели чем в KDE и других, то есть там явно отдельно сделано для Unity. Получается, это Ayatana? Может есть какие-нибудь плагины для плазмы, чтобы показывало такие индикаторы?

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

А кто сказал, что все реализации SNI-трея должны быть одинаковыми?

Получается, это Ayatana?

Нет, это sni-qt.

Darth_Revan ★★★★★ ()

трей не нужен, достаточно апплета, умеющего менять вид/поведение по событиям извне и запускать внешние команды

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

достаточно апплета, умеющего менять вид/поведение по событиям извне и запускать внешние команды

mate-indicator-applet подойдёт :3?

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