Какое DE или WM вы считаете самым дружественным для новичков?

А Циннамон пробовали?

На момент выбора циннамон грохался целиком при возникновении проблемы в любом апплете. Если это исправили — надо попробовать.

Тут ведь какое дело. 10 лет назад делали какое-то сравнение, выбрали мате. И всё, никто ничего менять не будет, работает и ладно.

ты снова забыл похмелиться с утра штоле? Как то иначе сложно объяснить рекомендацию использовать гном, да ещё и взрослым людям. Полагаешь у взрослых лдей больше желания и умения пердолиться с твиками и плагинами, чтобы довести наркоманское поделие до вменяемого вида?

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

В четвёртогноме твики уже не нужны, да и плагины тоже.

Настроек куча. Пользоваться кедами можно и из коробки, отключив akonadi и baloo. Кеды не обязывают юзера что-либо настраивать. А то что настроек полно - ничего плохого. Раз настроил, и забыл. Форматы конфигов в рамках мажорной версии не меняются, естественно. Годами можно юзать пятые кеды (обновляемые), и ничего заново не надо настраивать.

Пользоваться кедами можно и из коробки, отключив akonadi и baloo.

facepalm.jpg

«Изкаропки». Сириоузли? Всего лишь отключив какую-то неведомую хрень? И эти люди гонят на гном, в котором вообще ничего не надо отключать.

Раз настроил, и забыл.

Раз попердолился и забыл. Потом, через какое-то время будешь судорожно вспомнать, как же ты тогда пердолился, чтобы фича Н заработала.

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

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

Т.е. кеды можно рекомендовать только тем, у кого куча свободного времени? Я так и думал, и результаты опроса на ЛОРе это подтверждают, кстати. Тут полно людей с кучей свободного времени, поэтому кеды и на первом месте.

«Изкаропки». Сириоузли? Всего лишь отключив какую-то неведомую хрень? И эти люди гонят на гном, в котором вообще ничего не надо отключать.

Ой, да ладно. Интернет существует, google.

Раз попердолился и забыл. Потом, через какое-то время будешь судорожно вспомнать, как же ты тогда пердолился, чтобы фича Н заработала.

Я не знаю кто как. Пользуюсь дебиан, пришлось заново конфиги настраивать только после перехода с 4-х кед на 5. А так… Уже несколько лет настройки не редактировал, кеды как работали, так и работают.

Интернет существует, google.

Мы тут про дружелюбность к новичкам говорим вообще-то. Необходимость что-то гуглить, это нифига не дружелюбно. Change my mind.

Так можно юзать baloo и akonadi из коробки, можно и не отключать. Кеды не требуют какой-либо настройки.

Этим лишь заменятся одни проблемы на другие, из-за которых к такой отрисовке вообще перешли.

В GTK2 не было никаких сильно выделяющихся визуальных проблем. Как я уже говорил, GNOMEры просто решили забить на оконные менеджеры.

Вот поэтому GTK4 с аппаратной отрисовкой и GSK рулит.

Я уже рассказал почему software рендеринг надежнее. У GNOMEров как всегда: нужно сделать аппаратную отрисовку потому что «новамоладежна», а на последствия и недостатки наплевать.

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

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

wl_surface_commit

Соответственно эта штука - это вообще не то, это уже относится к композитору, который в Wayland - это каждый раз переизобретение колеса.

Оба — ХЗ что случилось, никакой конкретики.

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

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

Это не совсем баг в драйвере. Просто дискретная GPU, когда уходит в сон, вычищает текстуры VRAM. Приложение текстуру не отрисовало, потому что оно даже не знает что случилось. Ещё один вариант этой проблемы - это артефакты после выхода из сна. Тут вместо нулей уже рандомпамять. По идее видюха должна сохранять VRAM куда-то перед уходом в сон. Куда и как - вопрос. На встройках этой проблемы нет, потому что RAM используется как VRAM, а RAM сохраняется.

Откровенно говоря, переход на HiDPI-экран даже без субпиксельного рендеринга дал мне такое качество отображения шрифтов, с которым любые трюки на обычном экране и рядом не стояли. Физику не обманешь.

Понятно, ещё один свидетель HiDPI.

Это в чистом виде позиция потребителя. Решение о том, что должно быть, принимает разработчик, потому что ему это потом развивать и поддерживать.

Я вообще-то с позиции разработчика утверждаю что Wayland - какашка. :) Вот более конструктивная критика: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html

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

Типичный пользователь кед не знает baloo и nahernenadi.

Сам только неделю назад про них узнал и оставил, пофиг.

А что вообще за маниакальная тяга лезть в настройки? 2 компа с дефолтом стоят и всё прекрасно?

Есть настройки, их много, но не обязательно их менять, новичек может вообще ничего не настраивать, и пользоваться из коробки. Ваш изначальный комментарий: «138 проголосовавших за кеды, объясните, чем они таки дружелюбны к новичкам? Кучей настроек, равномерно размазанных по разным местам?», то что в нем много настроек, говорит лишь о том, что kde - очень гибкое окружение, к-е позволяет настроить многое. Для новичка вполне подходит, всё интуитивно понятно. Один раз настроил - забыл. Если новичек не хочет ничего настраивать - не проблема, пусть пользуется дефолтом. Всё просто.

С 2006 сидел только на GTK-окружениях, на крысе, потом на гноме, некоторое время на корице. Все это в основном под РАЧем последние лет 8. А недавно со мной случился катарсис: попробовал свежий KDE и понял, насколько я глубоко ошибался с выбором все это время и как был неправ, ругая и понося Qt. Я раскаиваюсь. Теперь только KDE и ничего кроме!

Как KDE вообще может быть дружественным с 100500 настроек?)

Как я уже говорил, GNOMEры просто решили забить на оконные менеджеры.

Если несколько раз повторить ложное высказывание, вернее от этого оно не становится.

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

Хоспади, что ж вы несёте… Значит, по-вашему, управляют местоположением и Z-порядком окон, передают события ввода и т.д. — сами клиенты?

Единственное, что «фигачится на клиенте», это декорации, и то не во всех DE — но это, внезапно, не является необходимой функциональностью менеджера окон.

Я уже рассказал почему software рендеринг надежнее.

Но и значительно менее производителен.

Соответственно эта штука - это вообще не то, это уже относится к композитору

Внезапно, композитор выполняет функции менеджера окон. И эта функция уведомляет композитор о готовности буфера, который теперь можно отобразить.

Это не совсем баг в драйвере. Просто дискретная GPU, когда уходит в сон, вычищает текстуры VRAM. Приложение текстуру не отрисовало, потому что оно даже не знает что случилось. Ещё один вариант этой проблемы - это артефакты после выхода из сна. Тут вместо нулей уже рандомпамять. По идее видюха должна сохранять VRAM куда-то перед уходом в сон. Куда и как - вопрос. На встройках этой проблемы нет, потому что RAM используется как VRAM, а RAM сохраняется.

Это будет ломать и Chrome, и многие-многие другие приложения, использующие аппаратное ускорение вывода.

Судя по документации Nvidia, есть способ сохранения VRAM на диск. Но в реальности это лишь костыль из-за того что они не осилили сделать, как Intel. Что ж, «молодцы» Nvidia…

Понятно, ещё один свидетель HiDPI.

Просто понимаю всю ограниченность попыток аппроксимации сложных векторных форм на матрицу 16×16.

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

Я вообще-то с позиции разработчика утверждаю

Отнюдь. «Хочу больше фич, ещё больше!» — это как раз позиция пользователя-потребителя. Опытный разработчик же понимает, что каждая новая функциональность пишется совсем не один раз, но потом ещё поддерживается, тестируется и т.д., отнимая человекочасы, а комбинаторный взрыв матрицы тестирования — это едва ли не худшее, что может приключиться с проектом. Поэтому опытный разработчик десять раз подумает, так ли нужна эта фича, оценит будущие затраты на её поддержку.

Так что выпиливание фич — это далеко не всегда минус; иногда это, наоборот, позволяет оздоровить проект. Скажем, KDE такая диета совсем не помешала бы.

Вот более конструктивная критика: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html

Уже читал, спасибо. Несмотря на то, что некоторые пункты критики заслуженные (как, например, фрагментация), многие не стоят выеденного яйца, а многие просто устарели.

Например, товарищ упоминает проблему с задержкой ввода из-за принудительного vsync, которую недавно устранили, позволив клиентам opt-in для отрисовки без синхронизации.

Критика цикла отрисовки с обратным вызовом вообще странная, мягко говоря. Пусть посмотрит, как работают многие игровые движки, и как там выполняется game loop. А если не устраивает frame throttling, то никто не мешает использовать неблокирующий вызов eglSwapBuffers(), установив swap interval в 0 и реагируя на frame events.

А ещё данный товарищ понятия не имеет, как работает масштабирование в иксах. Использование XRandr приводит к отвратительному результату, поэтому клиенты (тулкиты) масштабируются самостоятельно. Протокол для дробного масштабирования в Wayland как раз учитывает это, ибо он просто позволяет сообщить клиентам, с каким коэффициентом им следует масштабироваться самим.

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

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

+1

Автору опроса: «Где IceWM?» Тайловую экзотику включили, а IceWM обошли стороной.

Хоспади, что ж вы несёте… Значит, по-вашему, управляют местоположением и Z-порядком окон, передают события ввода и т.д. — сами клиенты?

Единственное, что «фигачится на клиенте», это декорации, и то не во всех DE — но это, внезапно, не является необходимой функциональностью менеджера окон.

Я не понимаю зачем было прикапываться к Z-order, который шарится между всеми окнами. Понятно же, что я говорил об окнах в плане декораций, которые в Wayland - clientside only.

Внезапно, композитор выполняет функции менеджера окон. И эта функция уведомляет композитор о готовности буфера, который теперь можно отобразить.

И этот композитор не только переизобретение колеса, а ещё и неюниксвейный большой кусок говна грязи, в который напихали весь функционал и сделали мегамонолитную архитектуру DE, в которой даже запись с экрана не работает без костылей.

Отнюдь. «Хочу больше фич, ещё больше!» — это как раз позиция пользователя-потребителя. Опытный разработчик же понимает, что каждая новая функциональность пишется совсем не один раз, но потом ещё поддерживается, тестируется и т.д., отнимая человекочасы, а комбинаторный взрыв матрицы тестирования — это едва ли не худшее, что может приключиться с проектом. Поэтому опытный разработчик десять раз подумает, так ли нужна эта фича, оценит будущие затраты на её поддержку.

Так что выпиливание фич — это далеко не всегда минус; иногда это, наоборот, позволяет оздоровить проект. Скажем, KDE такая диета совсем не помешала бы.

Всё что требовалось от Wayland это создать базовый фреймворк как в Xorg, в котором будут все базовые фичи, которые будут юзать DE, например перемещение окон и доступ окон друг к другу. Это единственный правильный подход, который уменьшает зоопарк реализаций и стандартизирует многие вещи, например, ту же запись с экрана. Всё что я слышу - это различные пиздежи вроде: «Wayland is just a protocol» (см. знаменитый тикет https://gitlab.freedesktop.org/wayland/wayland/-/issues/233). Потому что Wayland - это лаунчер для GNOME. Точка.

Так что никакого будущего у Wayland и в помине нет, потому что нет никакого «feature parity» с Xorg даже в теории. Всякие wlroots даже не предлагайте. Пока не сделают нормальный фреймворк по умолчанию, никто даже разговаривать не станет.

Я не понимаю зачем было прикапываться к Z-order, который шарится между всеми окнами. Понятно же, что я говорил об окнах в плане декораций, которые в Wayland - clientside only.

А теперь давайте взглянем, что же именно вы говорили:

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

Если для вас «все фичи менеджеров окон» — это нарисовать декорации, то у меня для вас плохие новости.

И этот композитор не только переизобретение колеса, а ещё и неюниксвейный большой кусок говна грязи, в который напихали весь функционал и сделали мегамонолитную архитектуру DE, в которой даже запись с экрана не работает без костылей.

Монолитность-немонолитность определяется не Wayland, а конкретной реализацией композитора. В KDE, вон, решили делать в отдельном процессе.

Но не суть. Суть в том, что высказанное вами же решение проблемы при изменении размера — «чтобы клиент возвращал бекенду callback, когда завершил отрисовку» — в Wayland фактически и используется.

Всё что требовалось от Wayland это создать базовый фреймворк как в Xorg, в котором будут все базовые фичи, которые будут юзать DE, например перемещение окон и доступ окон друг к другу.

Да-да, доступ окон друг к другу в стиле иксов, позволяя незаметно для пользователя делать снимки и подслушивать ввод даже находясь в песочнице — это то, что нужно!

см. знаменитый тикет https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

Посмотрел — увидел birdie со своим уже знаменитым агрессивным невежеством. А что я должен был там увидеть?

Так что никакого будущего у Wayland и в помине нет, потому что нет никакого «feature parity» с Xorg даже в теории.

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

Unity, конечно

Монолитность-немонолитность определяется не Wayland, а конкретной реализацией композитора.

Я уже начинаю фейспалмить. Ещё раз, в дисплейном сервере должна быть всего ОДНА реализация основного функционала необходимого для реализации любого DE. Именно в дисплейном сервере, а не в композиторе. Расширениями или нет значения не имеет. Менеджер окон управляет окнами и рисует декорации. Композитор занимается эффектами рабочего стола: прозрачность, шейдеры и так далее. У композитора тоже есть свой VSync. Композитор в том же Xorg - это необязательная вещь. Фичи для той же записи экрана и отдельных окон тоже должны быть частью дисплейного сервера. То что я перечислил - это здоровая экосистема, состоящая из независимых от друг друга компонентов. Не нравится менеджер окон? Взял и заменил на другой. Не нравится композитор? Поставил кастомный или вообще отключил его если он не нужен. Теперь сравните это всё с монолитными Wayland композиторами.

Но не суть. Суть в том, что высказанное вами же решение проблемы при изменении размера — «чтобы клиент возвращал бекенду callback, когда завершил отрисовку» — в Wayland фактически и используется.

Это не решение проблемы. Это альтернативный способ реализации ресайза. Он тоже не идеален. Решением проблемы в GTK3 - это делать так как было в GTK2/Qt.

Да-да, доступ окон друг к другу в стиле иксов, позволяя незаметно для пользователя делать снимки и подслушивать ввод даже находясь в песочнице — это то, что нужно!

Ещё один секюрный задрот. Смотрите, в X можно добавить систему разрешений, чтобы прежде чем получить доступ к окну или экрану нужно получить разрешение пользователя. Но любая система разрешений - это вещь, которую сложно реализовать. Тем более она скорее всего потребует изменений в приложениях. Поэтому люди просто не стали трахаться и оставили всё как есть. Это самый лучший вариант на данный момент. Кстати, говоря о вяленде, там вообще нет нормального способа получить изображение экрана, кроме как через порталы и Pipewire (спасибо разработчику Pipewire, что сделал хоть какой-то скриншаринг за вейландятлов). Про RDP вообще без комментариев, он невозможен в парадигме Wayland-а.

Вы забыли меня потраллить, что Xorg запускается от рута (иключение: форк иксов в OpenBSD)! Не дорабатываете.

Посмотрел — увидел birdie со своим уже знаменитым агрессивным невежеством. А что я должен был там увидеть?

Упыри боятся birdie как креста. :P Вы должны были увидеть что разработчики Wayland недоговороспособны и не собираются добавлять фичи, чтобы сделать Wayland полноценным фреймворком для десктопа, а не огрызком для запуска GNOME.

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

Вот в этом и проблема. Мегамонолит с изобретением велосипедов могут позволить себе только разработчики крупных DE и то не все, поэтому KDE в Wayland забагован и недопилен, а в Xorg KDE работает идеально (сужу по недавним репортам с phoronix). А разработчики маленьких DE просто выкинуты за борт.

А ещё данный товарищ понятия не имеет, как работает масштабирование в иксах.

С удовольствием почитаю в Вашем изложении, как же оно на самом деле работает.

Использование XRandr приводит к отвратительному результату

Это какое такое его «использование»? Влепить --scale на дисплей, что-ли?

Менеджер окон управляет окнами и рисует декорации

Уже хорошо, что вы наконец поняли, что менеджер окон занимается не только отрисовкой декораций.

Композитор занимается эффектами рабочего стола

Прежде всего он предоставляет буфер для off-screen рендеринга, избавляя приложения от необходимости перерисовывать дерево виджетов при expose. Да, далее он уже может накладывать на него всякие преобразования, а может и не накладывать.

Сначала менеджер окон, теперь композитор… — вы плаваете в терминологии.

Решением проблемы в GTK3 - это делать так как было в GTK2/Qt.

Ну конечно. А теперь отресайзите GTK2-приложение быстрым уверенным движением — и увидите ровно ту же самую картину с артефактами, когда тулкит не будет успевать за изменением размера окна. GTK3 просто медленнее перерисовывает.

Решение проблемы — именно решение, а не фиговый листок «если быстрее перерисовывать, то не так заметно» — синхронизация операции с менеджером окон. Как с самого начала работает сами-знаете-где.

Смотрите, в X можно добавить систему разрешений, чтобы прежде чем получить доступ к окну или экрану нужно получить разрешение пользователя

Опять двадцать пять… Ну вперёд — реализуйте, да так, чтобы не нарушить протокол и не сломать существующие приложения, в частности — гарантии возвращаемых значений в каком-нибудь GetImage.

Мне так нравятся диванные архитекторы, у которых всегда всё так гладко на бумаге!

спасибо разработчику Pipewire, что сделал хоть какой-то скриншаринг за вейландятлов

Разработчик PipeWire сделал мультимедиа-фреймворк. Screencast, очевидно, реализовали разработчики соответствующих композиторов, используя PipeWire как транспорт.

Вы забыли меня потраллить, что Xorg запускается от рута (иключение: форк иксов в OpenBSD)!

Вообще-то, уже давно вполне себе запускается от пользователя, как минимум при использовании GDM, благодаря KMS и интеграции с systemd-logind.

Вам бы матчасть подучить, прежде чем в споры вступать.

Добавлено: Ах да, как же я пропустил такое:

в Xorg KDE работает идеально (сужу по недавним репортам с phoronix)

Это просто прекрасно! Как говорят, «вы сделали мой день»!

Это какое такое его «использование»? Влепить –scale на дисплей, что-ли?

Ага.

С удовольствием почитаю в Вашем изложении, как же оно на самом деле работает.

Я же написал: клиенты (~тулкиты) масштабируются самостоятельно.

Самое забавное, что им ровным счётом ничто не мешает делать это и в Wayland прямо сейчас. Я уже как-то показывал Qt-приложение в масштабе 150%, нативно работающее в Wayland-сеансе GNOME 3.38 (использовалась переменная окружения QT_SCALE_FACTOR).

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

Тема про дружелюбность для новичков, которые очевидно приходят преимущественно с винды. Среднестатистический пользователь винды какими настройками пользуется? Правильно, абсолютно никакими. Потому что даже не знает о их существовании и ему это не интересно. Ну вот KDE из коробки выглядит максимально похоже на винду (ну насколько это вообще возможно в линуксе) и не требует для этого никаких настроек вообще. Если ты знаешь другое более напоминающее для новичка уютную винду без ковыряния в настройках подскажи, я такого не видел. Чтоб вот обязательно кнопка «Пуск» слева внизу и окошечки с крестиком вверху справа, ну и прочие элементы интерфейса чтоб как там. И общее ощущение как от винды, если ты понимаешь о чем я. Критика по поводу «настроек, равномерно размазанных по разным местам» возможно вполне справедлива, но не имеет никакого отношения в обсуждаемому вопросу хотя бы потому что в винде они размазаны еще в большей степени.

Среднестатистический пользователь винды какими настройками пользуется?

Выборка уходящих с винды на линукс отличается от «среднестатистического пользователя». Как правило, их давно что-то не устраивало, и они таки много чего пытались настроть, либо просто «продвинутые юзеры» (что тоже отличается от среднестатистического).

И общее ощущение как от винды, если ты понимаешь о чем я.

О страданиях? :)

Ну наконец-то Гноме4 на пятом месте. Лучше чтобы был на десятом, но он движется в этом направлении.

PS: В нем непонятно даже как окна переключать и как рабочий стол увидеть. Как такое можно использовать - совершенно неясно.

Выборка уходящих с винды на линукс отличается от «среднестатистического пользователя»

Далеко не все уходят добровольно, многих уходят принудительно. Моих филологов все устраивало в WinXP, поэтому Xubuntu, чуть поднастроенная на минимум отличий в расположении элементов интерфейса, позволила им не перенапрягаться в поисках «Пуска» и спокойно продолжать работать.

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

Cinnamon? Xfce в Xubuntu (разве что панель вниз переместить)?

Дефолт со светлой темой идентичен винде, даже посимпатичнее. И если что-то таки захочется поменять, это делается в 2 клика без пердолинга стандартными средствами.

даже посимпатичнее

Ну хз. Винда хотя бы не страдает гигантизмом.

свой VSync

В Wayland добавили отключение VSync.

Композитор в том же Xorg - это необязательная вещь

Не просто композитор, а композитный оконный менеджер, реализующий протокол Wayland. В X.Org оконные менеджеры — тоже обязательная вещь на практике, т. к. X.Org без оконных менеджеров никто не пользуется на desktop'е. Причём это ещё и те же самые менеджеры окон зачастую (Mutter, KWin), либо другие, но тоже композитные (Compiz, Muffin).

Про RDP вообще без комментариев, он невозможен в парадигме Wayland-а

Тебя забыли спросить и реализовали.

Очередную перепись кедоводов можно считать состоявшейся?

Ага.

А зачем?

Я же написал: клиенты (~тулкиты) масштабируются самостоятельно.

И это правильно. А нужна какая-то «магия»?

Самое забавное, что им ровным счётом ничто не мешает делать это и в Wayland прямо сейчас.

Так а как по-другому Вы хотели? Или вы под «масштабированием» подразумеваете не resolution independence, а все-таки scaling.

А зачем?

Это не ко мне вопрос. Я выступаю за масштабирование самими тулкитами, ибо им намного лучше знать контекст элементов окна. Увы, в GTK поддержку дробного масштабирования ждать придётся ещё долго.

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

Остальные ваши вопросы исходят из ложного предположения

Все мои вопросы исходят из того, что после Вашего громкого заявления:

А ещё данный товарищ понятия не имеет, как работает масштабирование в иксах.

я попросил рассказать, как же оно все на самом деле, но Вы как-то не очень разговорчивы. Из уже сказанного Вами понятно лишь что:

1. использование XRandr в виде --scale приводит к отвратительному результату
2. поэтому клиенты (тулкиты) масштабируются самостоятельно (нет, не поэтому)
3. зачем так использовать XRandr вы и сами не знаете
4. протокол дробного масштабирования в Wayland учитывает «это»: чтобы запустить Qt-приложение с масштабом 150% в Wayland-сеансе GNOME надо устанавливать переменные окружения
5. GTK не умеет в дробное масштабирование (Вы какую ее версию имели в виду, кстати?)

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

blackbox

Ванильный гном в Ubuntu.

Для пользователя удобнее всего deepin. Слава Уханю.

Cinnamon имхо лучшее, что случалось с линуксовым десктопом. Ну, после LXDE конечно, но там минимализм.

MATE тоже вполне себе приличный.

Где Window Maker?

Крыска достаточно проста для новичка

Это косяк, да, и серьёзный. И автора, и мой, я тоже не вспомнил.

Но с другой стороны — опрос висел в неподтверждённых почти 2 месяца, и из заглянувших в неподтверждённые за это время никто не вспомнил про IceWM. Зато сразу после — это пожалуйста. Опрос, который мы заслужили.

С третьей стороны, за пункт «Другой классический», куда теперь, по идее, должно слиться голосование за IceWM, пока подано всего 8 голосов. За все неучтённые другие. Это значит, что если бы IceWM был отдельным пунктом, то в самом лестном для него случае он был бы там же, где и сейчас — чуть пониже Budgie и чуть повыше sway и прочей «тайловой экзотики». А может, и пониже sway бы оказался.

Но да, я согласен, в целом это косяк.

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

Сам на десктопе пользуюсь крыской. На домашнем серверке i3.

самое «вендовое» было qvwm95 )))))) и эта, почему-то в спике нет Enlightment

qvwm95

Внешним видом почти не отличается от IceWM.

самое «вендовое»

XPde, XPQ4 для Q4OS и Chicago95 для Xfce.

Enlightment

Этой штукой все восхищаются, но никто не использует.

я попросил рассказать, как же оно все на самом деле, но Вы как-то не очень разговорчивы.

«Как же оно на самом деле» — это максимально расплывчатое определение. Что конкретно вас интересует?

поэтому клиенты (тулкиты) масштабируются самостоятельно (нет, не поэтому)

Имелось в виду «поэтому используется масштабирование тулкитами». Понятно, что в Qt не завозили DPI awareness, только потому что в Linux под X11 что-то там…

зачем так использовать XRandr вы и сами не знаете

Очевидно, чтобы установить отношение виртуального разрешения к физическому. Например, если виртуальное разрешение (то, с которым происходит отрисовка) — 5760×3240, а физическое — 3840×2160, то коэффициент будет равен 1½.

Так можно получить несколько лучшее воспринимаемое качество изображения при «дробном» масштабировании, сначала делая upscale ×2 средствами тулкита при виртуальном разрешении, равном физическому, умноженному на коэффициент масштабирования, а затем делая downscale с помощью xrandr до физического. Это даёт лучшее качество, чем «в лоб» уменьшение виртуального разрешения ниже физического, однако приводит к повышенному потреблению ресурсов из-за рендеринга в более высоком разрешении.

Данная схема используется, например, в экспериментальной реализации дробного масштабирования в GNOME на X11. Похожий принцип используется и в Mac OS.

GTK не умеет в дробное масштабирование (Вы какую ее версию имели в виду, кстати?)

GTK не поддерживает DPI scaling (кроме шрифтов), все актуальные на данный момент версии.

протокол дробного масштабирования в Wayland учитывает «это»: чтобы запустить Qt-приложение с масштабом 150% в Wayland-сеансе GNOME надо устанавливать переменные окружения

Что за чушь? Покажите, где я утверждал, что протокол дробного масштабирования в Wayland требует установку переменных окружения.

Вообще-то, этот протокол описывает уведомление клиента о предпочитаемом коэффициенте масштабирования через отправку события.