CSD. Зачем и почему?
В этой статье я развеиваю все мифы и опасения, касательно Client Side Decorations (CSD) и сравниваю эту технологию с Server Side Decorations (SSD). Разбор CSD будет в контексте графического окружения GNOME, но большая часть сказанного будет применима к любому CSD, не только в GNOME.
Что такое CSD?
Почти у всех приложений есть заголовок и рамка окна. Это, так называемые, декорации приложения. Помимо внешнего вида, декорации ещё и отвечают за то, как окно может менять размер и обновлять своё содержимое при перемещении. Декорации могут быть реализованы на стороне графического сервера (SSD — Server Side Decorations), а могут на стороне приложения (CSD — Client Side Decorations). При отрисовке на стороне клиента, у приложения есть контроль за содержимым декораций и приложение может позволить себе такие штуки, как headerbar — о чём далее и пойдёт речь.
Разница между titlebar и headerbar
Раньше было популярно делать приложения с titlebar: у приложения был заголовок окна, в котором располагались лишь элементы управления окном и название окна. Часто под заголовком окна располагалось меню с выпадающими списками.
Позже появилась концепция headerbar — разработчики поняли, что вместо бесполезного названия окна, можно поместить в заголовок окна полезные элементы — вкладки, кнопки и прочее. Когда используют headerbar, меню с выпадающими списками обычно является дурным тоном.
Иногда, когда приложению нет смысла иметь хоть какой-то заголовок, заголовок не отрисовывается, а кнопки управления окном убираются в тело самого приложения.
Самые частые комбинации вышеописанных технологий: titlebar+SSD и headerbar+CSD. Хотя ничего не мешает использовать titlebar с CSD. Обратите внимание, что headerbar и кнопки управления окном внутри тела приложения возможны только при работе CSD!
Преимущества, которые даёт CSD
Отказ от titlebar экономит вертикальное пространство
Firefox 92. Слева классический заголовок, а справа — headerbar. Кто в здравом уме согласится потратить столько места ради названия окна и кнопки закрытия?
Зачем Blender titlebar? В названии нет ничего полезного, а кнопку закрытия можно поместить в само приложение.
А в заголовке окна Apostrophe много полезных кнопок. Благодаря headerbar, полезная площадь окна не простаивает.
Многие приложения лучше выглядят без titlebar
В новом GNOME Text Editor тема отвечает за всё: цветовую палитру приложения, цветовую схему текста в редакторе и цвет заголовка окна. Выглядит очень круто:
Мифы и заблуждения о CSD/headerbar
Некоторые приложения выглядят инородно без SSD.
Очень часто приводят аргумент, что на Wayland сессии GNOME не поддерживает SSD, из-за чего некоторые приложения отрисовывают рамку окна, внешне отличную от стандартной. Но в чём смысл одинаковых заголовков окон для всех приложений в системе, если сами приложения выглядят (UI) и ощущаются (UX) по-разному?
Сравните сами:
Обратите внимание, с каждым скриншотом всё меньше в пустую потраченного пространства. В варианте без CSD, заголовок хоть и имеет цвет как у нативных приложений (тема Adwaita), но совершенно не сочетается с внешним видом Telegram: используется другой цвет (это особенно хорошо видно, если в приложении светлая тема, а в системе тёмная или наоборот), в самом Telegram тема не выглядит как Adwaita, анимации другие, как и расположение элементов интерфейса. Нет никакого смысла в идентичных заголовках между приложениями, если сами приложения написаны по разным гайдлайнам и сильно разнятся по вопросам UI/UX. У вас никогда не будет полной консистентности внешнего вида приложений и пользовательского опыта. Всегда будет хотя бы одно нужное приложение на другом тулките: Qt, Electron, FLTK, EFL, SixtyFPS, ImGui, Motif, etc. Поэтому и нет смысла гнаться за одинаковыми заголовками окна для всех приложений в системе.
Разработчики GNOME форсируют CSD, банально не поддерживая протокол xdg-decorations на Wayland
На самом деле, любое приложение, поддерживающее Wayland, обязано поддерживать CSD и учитывать, что Wayland-композитор может не поддерживать SSD (протокол xdg-decorations). Потому что xdg-decorations является опциональным протоколом[^1] и его запросто может не быть на IoT устройствах (киоски, информационные стенды, банкоматы, etc.); игровых консолях (Steam Deck), планшетах (JingPad A1, PineTab) и смартфонах (Librem 5, PinePhone).
Из портативных композиторов, xdg-decorations не поддерживается как минимум в Mir из Ubuntu Touch — используется в смартфонах и планшетах, и ещё в двух он прилетает бонусом из-за использования wlroots, но не используется для согласования SSD: gamescope — композитор для портативной сессии Steam Deck и Phoc из Phosh — используется во многих дистрибутивах для смартфонов и дефолт для Librem 5. Среди десктопных композиторов ситуация аналогичная, SSD далеко не стандарт: Mutter (GNOME WM), Weston и Enlightenment не поддерживают протокол xdg-decorations. Кто-то скажет: Какая разница, что все эти композиторы не поддерживают SSD, ведь KWin и wlroots её поддерживают! Ну, не поддерживающих композиторов явно больше, как по количеству, так и по доле рынка: Steam Deck планирует разойтись сотнями тысяч экземпляров, если не миллионами, GNOME самое популярное DE в Linux (пруф раз, пруф два (см. Main Findings)), а Weston используется не только в качестве референсного Wayland-композитора, но и в качестве композитора для WSLg.
Алсо, если приложение не поддерживает Wayland и работает через X11, то XWayland в GNOME вполне себе поддерживает SSD. Таким образом, для устаревших приложений не ломается совместимость.
Исходя из этих фактов, разработчики GNOME не видят смысла поддерживать SSD для Wayland приложений в GNOME: CSD позволяет делать и titlebar, и headerbar (который обычно лучше выглядит), а ещё разработчикам не надо тратить, пусть и минимальные, но дополнительные ресурсы на поддержку SSD в Wayland. Если какое-то приложение заявляет о поддержке Wayland, но не реализует CSD, то баг именно в приложении, потому что SSD необязателен для Wayland, а вот CSD очень даже обязателен[^1].
[^1]: XDG decoration. A client can use this protocol to request being decorated by a supporting compositor. If compositor and client do not negotiate the use of a server-side decoration using this protocol, clients continue to self-decorate as they see fit.
Пропадает название окна, из-за чего трудно ориентироваться
Тут уже всё сильно зависит от графического окружения, в GNOME такой проблемы нет:
- Есть Overview (Обзор), в котором очень легко ориентироваться по миниатюрам окон.
- В GNOME очень грамотная реализация переключения между окнами.
Alt+Tab/Super+Tabпереключает между открытыми приложениями, аAlt+`/Super+`переключает между окнами одного приложения и показывает их заголовки.
Пропадает возможность перетащить окно или воспользоваться контекстным действием по ПКМ
У большинства приложений с CSD всё равно есть немалая область в заголовке, за которую можно ухватиться и сделать задуманное. Проблемы возникают только в случае большой загруженности заголовка различными кнопками или вкладками. И это легко решается, даже если вы не хотите выцеливать три с половиной пикселя:
- Контекстное меню у окна в GNOME вызывается сочетанием клавиш
Alt+Space. - Некоторые CSD приложения перетаскиваются за любую часть окна, как, например, Clapper.
- Окна в GNOME перетаскиваются зажатием клавиши
Superи удержанием левой кнопки мыши. И для этого даже не надо быть наведённым на заголовок окна! Чем меньше приходится мышевозить — тем лучше.
CSD заставляет разработчиков переходить на headerbar, либо убирать заголовок окна вовсе
Бред.
CSD вынуждает разработчиков приложений писать лишний код
Любой современный тулкит (GTK3, GTK4, Qt5, Qt6, SDL2, etc.), кроме Electron, поддерживает CSD на Linux. В Electron работа над поддержкой CSD для Wayland ведётся, хотя всё равно Electron приложения пока что не поддерживают Wayland полноценно и работают через XWayland.
Для тех, кто не использует ни один из этих тулкитов есть библиотека libdecor, которая позволяет с лёгкостью добавить CSD.
Отказ mpv поддерживать CSD
Разработчик mpv (wm4) высказывался резко негативно по поводу CSD, а потом бац и mpv умеет в CSD:
Вообще, история с mpv и wm4 (создатель mpv) весьма забавная. Сначала, wm4 добавил коммит в mpv, который завершал работу mpv на GNOME с сообщением об ошибке. Потом сменил завершение на простое предупреждение пользователя, что “на GNOME что-то может пойти не так”. А потом его выгнали из собственного проекта. Выгнали его, конечно, не конкретно за изначальный коммит для GNOME, а скорее за то, что он был очень негативной личностью. Оригинальный аккаунт wm4 на GitHub уже удалён, чем воспользовались тролли, которые создали фейковый аккаунт. Похоже, он был редкостным мудаком:
Из-за CSD нарушается общий UX ресайза окон
Это единственный реальный минус, который несёт в себе CSD. На плечи разработчиков тулкитов ложится задача правильно реализовать ресайз окон, чтобы он был удобен для пользователя. И проблема в том, в разных тулкитах ресайз окон реализован по-разному: разные зоны чувствительности, плавность анимаций и прочее. В идеале, должна быть общая договорённость между тулкитами (HIG, стайлгайды) как реализовывать ресайз для CSD, но мир неидеален и такой договорённости нет. В любом случае это не столь существенный минус, на фоне всех плюсов, что привносит CSD.
А что у других ОС?
Windows
В графической системе Windows нет понятия клиента и сервера, но если сторить аналогию, то в Windows всё-таки CSD. Нативные тулкиты разной степени свежести: Win32 (WM_NCPAINT) и UWP (ApplicationViewTitleBar) рисуют свои декорации для окон. Microsoft старается использовать headerbar в своих новых приложениях.
macOS
В macOS помимо CSD, headerbar'ы во все поля для дефолтных приложений.
Заключение
CSD — хороший тренд в построении графических интерфейсов для настольных компьютеров. Приложения становятся красивее и компактнее. CSD уже во всех мейнстримных ОС и с каждым годом становится всё популярнее. А попытка отрицать CSD — банальный страх перемен и привязанность к своим привычкам.