Мой опыт с рабочими столами Linux

Что происходит, когда чёрный лебедь просыпается ото сна, где он был белым лебедем?

Последние 2.5 года я использовал Linux на своих основных устройствах. Большую часть этого времени я пробовал разные способы кастомизации рабочих столов, а в какой-то момент стал разрабатывать свои инструменты. В этом посте хочется подвести промежуточный итог своему опыту с десктопами, рассказать о той самой системе виджетов и поделиться своими планами.

С чего все началось

Полтора года назад я уже рассказывал о том, как познакомился с Linux’ом, но в том посте больше внимания уделено использованию ОС в целом — здесь же хочется уделить внимание рабочим столам.

Моим первым дистрибутивом был Linux Mint . Мне кажется, это один из лучших дистрибутивов для тех, кто хочет перейти с Windows или macOS. Дистрибутив доступен в 3-х изданиях, основным из которых является версия с рабочим столом Cinnamon. Я выбрал эту версию. На мой взгляд, привыкнуть к этому рабочему столу довольно просто, как и в целом его использовать. Я быстро смог адаптироваться к нему, хотя до этого не использовал Linux на десктопах.

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

Но в какой-то момент и этого стало мало, и я стал искать способы настроить систему ещё больше. Так я открыл для себя мир тайлинговых оконных менеджеров.

Их идея состоит в следующем: окна располагаются не «как придется», а по строго определенным правилам, как плитки, занимая все свободное пространство и не перекрывая друг друга. Но будет понятнее, если я заменю тысячу слов одной картинкой:

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

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

Первые три месяца я использовал AwesomeWM . Потом мне стало скучно, и я решил настроить ещё один оконный менеджер — bspwm . Если AwesomeWM реализует какие-то функции помимо расстановки окон, то bspwm делегирует все остальные задачи сторонним программам. Такой подход мне понравился больше, и следующие несколько месяцев я использовал уже его.

А потом я узнал про Wayland.

Wayland?

То, что я рассказал выше, целиком и полностью об одной оконной системе — X11. Но существует и другая, более новая — Wayland. И то, и другое — это лишь набор протоколов, для которых есть конкретные реализации. Для X11, если говорить про Linux, то это Xorg. А с Wayland’ом ситуация иная — реализаций достаточно много. Эти реализации называются Wayland-композиторами. В отличие от оконных менеджеров в X11, композитор отвечает не только за расстановку окон, но и за множество других задач.

На тот момент крупные окружения рабочих столов, GNOME и KDE, уже поддерживали Wayland, но мне, очевидно, были интересны более минималистичные решения. Я довольно быстро наткнулся на Hyprland — один из наиболее популярных Wayland-композиторов, который «из коробки» поддерживает функции, позволяющие сделать рабочий стол красивым. При этом это не полноценное окружение рабочего стола, поэтому настраивать все компоненты все так же придется самому.

После Hyprland’а я на короткое время вернулся на bspwm, затем попробовал SwayFX , затем вновь Hyprland, и, наконец, нашел niri .

Про этот Wayland-композитор я рассказывал в том же посте. В отличие от классического тайлинга, niri использует скроллинг: окна расположены на бесконечной «ленте», уходящей вправо, благодаря чему открытие новых окон не изменяет размер старых. Переходить на какое-то другое решение я не планирую, если только не решу написать свой Wayland-композитор .

Оболочки

Но как я сказал ранее, одного оконного менеджера или Wayland-композитора недостаточно для повседневного использования. Обычно полноценные окружения включают панель, меню запуска приложений, блокировщик экрана и многие другие компоненты. В моем случае их приходилось выбирать по отдельности: Waybar в качестве панели, wofi для запуска приложений и так далее. Все вместе эти компоненты принято называть оболочкой.

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

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

Своя оболочка?

Наверное, я хотел разобраться в устройстве этих систем. Это лучший ответ на вопрос «зачем?» (который кто-нибудь обязательно задаст), на который я способен.

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

В феврале 2025 года я приступил к разработке. Все началось с меню питания , которое я разработал как пример использования нужного набора библиотек в Go. Затем написал ещё несколько компонентов: док (подобный тому, что есть в macOS, но более простой), лаунчер, демон уведомлений. Далее я попробовал сделать более общую систему, которая позволяла программировать свои компоненты рабочего стола.

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

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

Последний коммит я сделал в октябре. Более подробная информация о проекте есть на соответствующей странице. Исходный код я также решил не выкладывать — пусть этот проект будет забыт на задворках моей файловой системы. Впрочем, исходный код библиотек можно найти у меня на GitHub .

В поисках простоты

Обычно я предпочитаю простые, минималистичные решения для чего бы то ни было. Это проявляется во всем. Одной из причин, по которой мне не удалось разработать свою оболочку, стала, как мне кажется, излишняя сложность. Я использовал тулкит GTK 3, который довольно сложно устроен. Язык Go добавил сложность из-за специфики использования этого тулкита в других языках. Абстракция за абстракцией, устройство системы становилось все запутаннее и запутаннее, сложнее и сложнее. Я отошел от своих стандартов, что и привело к неудаче.

Сложность — это не всегда плохо. Некоторые системы сами по себе сложные, их не получится написать «просто». Но излишние переусложнения там, где они не нужны, — это, на мой взгляд, большая ошибка, которую совершают очень многие люди. И речь не только о разработке ПО.

Мне нравится, как о сложности пишет создатель GUI-библиотеки Iced:

Сложность — это плохо. Она проникает. Безмолвно. Незамеченно. А потом она убивает всё. Медленно. Я видел, как это происходит снова и снова. Многие из моих кодовых баз медленно и мучительно погибли в её руках.

Планы

Я хочу ещё раз попробовать реализовать компоненты рабочего стола. Но в этот раз постараюсь не допускать той ошибки, о которой написал выше.

Будут изменения и с технологической точки зрения. В последнее время я начал писать на Rust. Конечно, пока я не могу назвать себя экспертом в этом языке, но все впереди. Как мне кажется, Rust больше подходит для разработки десктопных приложений, чем Go. Также я решил заменить GTK на другой тулкит.

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