Firefox включает полноценную поддержку Wayland

Это всё присутствует и в gtk3

Да. Только в GTK 4 это всё ещё больше ощущается. Причём мне GTK в целом нравится больше, чем монструозный Qt. Я был очень доволен GTK 2. Не так много нужно было, чтобы осовременить GTK 2: добавить поддержку HiDPI и Wayland и по мелочи пройтись напильником. Зачем было ломать функциональность и выкидывать столько всего из тулкита, при этом ещё умудряясь ухудшить производительность? Риторический вопрос. Очевидно, Red Hat решало только свои задачи, т. е. делала конкретно то, что нужно было ей.

при этом ещё умудряясь ухудшить производительность

А ещё навязывает hardware-backend, который мешает запуску по сети (по сути его выкидывает нафиг) и в котором ШГ (шрифты мыльцо). Ну и периодические глюки на драйверах - это тоже случается на hardware backend-ах.

Самое смешное, что GTK2 позволяет большую кастомизацию оформления и при этом работает БЫСТРЕЕ.

В GTK3/4 всё прибито на квадратно-гнездовой CSS (при этом на неполноценный CSS, потому что дерево виджетов в GTK - это один хрен не разметка HTML) и вместе с тем требует БОЛЬШЕ вычислительных ресурсов.

Деградация ценой потери производительности.

Сегодняшний стек Гнома реализует весь тот говнодизайнерско-маркетоидный абсурд, который tonsky разбирает в своём блоге уже много лет: https://grumpy.website/

который tonsky разбирает в своём блоге уже много лет:

кто этот клоун?

Из реальных проблем в GTK2:

• Определения struct объектов являются частью публичного интерфейса, а не инкапсулированы за методами. Решение этой проблемы потребовало полностью сломать ABI, поэтому они довольно долго тянули до ввода GTK3, когда накопилась критическая масса идей, ради который стоило бы идти на такой кардинальный шаг, чтобы сразу всё воплотить.
• Как следствие предыдущего. В одной из структур фигурирует 32-битное значение под счётчик времени, и это нельзя исправить без поломки ABI. Если не ошибаюсь, это связано с кодом всплывающих подсказок. Поэтому если это не править, то в 2038-м этот код сломается.
  • В качестве решения я вижу изменить внутреннюю логику кода так, чтобы счётчик хранил относительное значение времени - отсчитывая разницу от момента запуска программы. Это починит логику, не сломав ABI.
• В GTK2 приложение линкуется с библиотекой вида libgtk-x11-2.0.so.0, то есть она связана с конкретным бэком. В GTK3 этот вопрос решили, приложение линкуется с libgtk-3.so.0. И теоретически, если не использует ничего, специфичного для конкретного бэка, то может прозрачно работать на любом бэке.
  • Для GTK2 этот вопрос можно решить, оставив libgtk-x11-2.0.so.0 как легаси-имя. То есть теоретически вполне возможно существующие собранные программы на GTK2 запустить на другом бэке, если доработать тулкит.
• HiDPI. Нужно допиливать. Тупо не завезено API под это дело, нужно завозить.

И да, реализация масштабирования UI в GTK3/4 - сосёт. Они отмазываются тем, что «реализация дробного масштабирования требует поддержки со стороны приложений». А миграция с GTK3 и GTK4 - не требует что ли??

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

Напоминаю, что в Qt дробное масштабирование сделали.

Hidpi нормального и на gtk3 нет. Точнее, они всё, что от 96 до 2x96 hidpi не считают. В том числе популярные 141dpi.

А в одном предыдущем сраче вопрос поднимался: оказалось, что разработчики вайланда приняли политическое решение, что масштабирование тулкитов может быть только целочисленным. т.е. между 96 и 192 нет никаких dpi. Ну и некоторые извращнцы извратились, отрендерили в х5 а потом уменьшили в 4 раза - так получился масштаб 1,25.

Ну и некоторые извращнцы извратились, отрендерили в х5 а потом уменьшили в 4 раза - так получился масштаб 1,25.

За такое нужно выгонять из профессии за профнепригодность.

В той статье от разработчика mpv в предыдущес сраче. Если я правильно понял - это сейчас мейнстрим.

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

Что. Вы. Несёте. 🤦

Ничто не мешает тулкиту самостоятельно осуществлять какое хотите масштабирование. В X11 они ровно это и делают.

Ничто не мешает тулкиту самостоятельно осуществлять какое хотите масштабирование.

Именно так. Теперь вопрос: почему в GTK так и не сделали дробное масштабирование КАК ПОЛОЖЕНО, а воткнули костыль через рескейл в Wayland-композиторах? Причём костыль, за который можно без зазрения совести давать пожизненный бан и выкидывать на мороз. В Qt дробный скейлинг как раз сделали.

почему в GTK так и не сделали дробное масштабирование КАК ПОЛОЖЕНО

Без понятия. Наверное, потому что это не так-то просто сделать.

В Qt дробный скейлинг как раз сделали

С артефактами.

Хотя так лучше, чем совсем никак. Благо хоть DPI-масштабирование шрифтов поддерживается и там, и там.

Без понятия. Наверное, потому что это не так-то просто сделать.

А может потому что не хватает компетенции? Неосиляторы.

С артефактами.

Давай честно, у тебя кончились аргументы, и ты это сейчас придумал. Потому что никаких артефактов и в помине нет. Я сделал скейлинг 1.05 и всё было идеально ровно.

Давай честно, у тебя кончились аргументы, и ты это сейчас придумал. Потому что никаких артефактов и в помине нет.

Я уже когда-то давно выкладывал снимки экрана. Насколько помню, линии разделителей в меню были разной толщины, в KolourPaint вертикальная линия в 1 пкс выглядела вдвое толще горизонтальной, и проч.

Вот это сообщение, но ссылки, увы, протухли.

Это не артефакты, это просто картинка не влезает в сетку пикселей и происходит интерполяция, что при определённых значения скейла вполне нормально. Суть в том, что в Qt скейл сделали нормально и его можно юзать без костылизма с апскейлом фреймбуфера через композитор. К тому же обычно дробный скейл юзают: 1.25, 1.5, 1.75. Другие - хз, если конечно нет совсем маргинальных разрешений, но даже в таких правильный скейл должен влезть нормально.

Это не артефакты, это просто картинка не влезает в сетку пикселей и происходит интерполяция, что при определённых значения скейла вполне нормально.

«Это не артефакты, а артефакты».

Впрочем, такая опция со всеми своими недостатками всё равно лучше, чем её отсутствие, спору нет.

Без понятия. Наверное, потому что это не так-то просто сделать.

После того, как они перенесли всю отрисовку виджетов на какую то js/css подобную векторную фигню, так ещё и редуцировали большую часть элементов до пустого места? Что то как то слабо верится.

Благо хоть DPI-масштабирование шрифтов поддерживается и там, и там.

Если бы они ещё и шрифт нужного размера разучились рисовать - можно было бы сразу утилизировать.

После того, как они перенесли всю отрисовку виджетов на какую то js/css подобную векторную фигню, так ещё и редуцировали большую часть элементов до пустого места? Что то как то слабо верится.

Дело в том, что тупо интерполировать – значит получить мыло. Почитайте, какую эвристику использует та же Windows, чтобы максимально избегать мыла с одной стороны, и артефактов масштабирования с другой.

Но там нет никакой необходимости что то интерполировать! При любой векторной отрисовке где то есть переменная масштаба и её надо просто подправить.

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

С виндой скорее всего что то другое - виджеты win32 вроде бы не масштабируемые. Но напортачили то они с текстом. Хз как, но видимо просто приняли решение растянуть и не париться. Так проще и точно ничего не сломается по совместимости.

Но там нет никакой необходимости что то интерполировать! При любой векторной отрисовке где то есть переменная масштаба и её надо просто подправить.

Ну вот стоит у вас в CSS border: 1px solid #000000 — что делать при масштабировании 150%?

Если, как предлагают ниже, округлять до ближайшего целого, то тогда пусть имеем две линии: 1 пкс и 2 пкс; при масштабировании 150% вторая станет 3 пкс, а вот первая — 1,5, и округление в любую сторону нарушит оригинальное соотношение 1:2.

Короче, все эти «да можно просто…» — это рассуждения с дивана. Всё всегда кажется простым, если исходить из упрощённых моделей, не учитывающих весь спектр реальных применений. «Гладко было на бумаге».

К слову сказать пиксели в CSS могут быть дробными. Но то как это будет отрисовано - зависит от браузера.

Короче, все эти «да можно просто…» — это рассуждения с дивана. Всё всегда кажется простым, если исходить из упрощённых моделей, не учитывающих весь спектр реальных применений

Лучше конечно ничего не делать, а то перфекционисты будут страдать. А так страдают все, справедливость восторжествовала.

Я себе для ноута просто делал темы с увеличенными размерами для гтк3 и гтк2. Да, неидеально, но это работало. Не ждать же пока упоротые раздуплятся. У них кстати и целочисленное масштабирование кривое, куда им дробное ещё.

Ну вот стоит у вас в CSS border: 1px solid #000000 — что делать при масштабировании 150%?

Написано 1 пиксель? Рисуем 1 писель. Если мы предполагаем что дизайнер знал что делал.

Если мы предполагаем что дизайнер - _удак, тогда нужно подумать. Например рассчитать чему должен быть равен 1 дефолтпиксель на например 96ppi и исходя из этого пересчитать всё в милиметры а затем округлить до ближайшего целого. Но со шрифтами, наклонными и кривыми это плохо работает, так что выбираем подходящий режим субпиксельного сглаживания (а ещё лучше - даём на выбор юзеру) и применяем его на всё а не только текст.

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

Лучше всего конечно не рисовать пикселями векторную графику.

Так как я против думания за разработчика и искуственного урезания функционала - не буду предлагать выпилить из css для интерфейсов пиксельной отрисовки. Но предупреждение об ошибке выдавать нужно (разработчику). А так как некие области очевидно будут заливаться битмапами (в пикселях), то видимо стоит интерполировать со сглаживанием. Размеры области то заданы в милиметрах.

Написано 1 пиксель? Рисуем 1 писель.

И получим отсутствие масштабирования отдельных элементов интерфейса.

Например рассчитать чему должен быть равен 1 дефолтпиксель на например 96ppi и исходя из этого пересчитать всё в милиметры а затем округлить до ближайшего целого.

И получим артефакты. Например, имеем идущие рядом чёрную линию #1 в 1 пиксель, белую #2 в 1 пиксель и чёрную #3 в 2 пикселя. При масштабировании в 150% они все вместе должны отмасштабироваться в (1 + 1 + 2) * 1,5 = 6 пикселей. Линия #3 масштабируется нацело и займёт 2 * 1,5 = 3 пикселя, и остальные 3 пикселя останутся для линий #1 и #2. Какая из них должна быть округлена в какую сторону? Как решить, отдать белой линии 2 пикселя, а чёрной 1, или наоборот? И что делать с тем, что бывшие одинаковыми линии теперь в 2 раза отличаются по ширине?

интерполировать со сглаживанием

И получим мыло.

Ещё раз повторяю: задача дробного масштабирования интерфейса совсем не настолько тривиальна, как кажется с дивана.

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

А невозможно сначала нарисовать векторную графику в пикселях, а потом отмасштабировать без артефактов. Это можно сделать только достаточно хорошо и это лучше чем вообще никак или плохо.

задача дробного масштабирования интерфейса совсем не настолько тривиальна, как кажется с дивана.

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

По факту gtk2 и xterm всё ещё лучше адаптируются к hidpi (ну, если не учитывать разнокалиберный многомонитор). Хотя gtk3 якобы изначально создавалась в т.ч. для лёгкого масштабирования через векторную отрисовку. Что у них пошло не так?

А невозможно сначала нарисовать векторную графику в пикселях, а потом отмасштабировать без артефактов

Очень даже возможно: целочисленное масштабирование происходит без потери информации. В случае дробного же — да, очень сложно добиться приемлемого результата.

Это можно сделать только достаточно хорошо и это лучше чем вообще никак или плохо.

С этим вроде никто и не спорит. Просто я объяснил, что задача эта далеко не такая простая, как может показаться на первый взгляд.

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

Очень даже возможно: целочисленное масштабирование происходит без потери информации.

Так целочисленное несостоятельно. Между 1, 2 и 3 находится ~80% существующих мониторов и для них нужно дробное.

но всё равно артефактов при дробном масштабировании не избежать.

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

Так целочисленное несостоятельно. Между 1, 2 и 3 находится ~80% существующих мониторов и для них нужно дробное.

Почему-то Apple додумалась для всех своих продуктов использовать одинаковую плотность пикселей в рамках линейки, а при переходах увеличивать её на целые коэффициенты, т.е. целевые показатели – плотность пикселей и диагональ, а не разрешение.

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

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

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

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

Кстати, угадайте, как в MacOS работает нецелочисленное масштабирование.

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

Так, стоп, это мониторы существуют чтобы разработчикам тулкита было удобно писать код, или это наоборот, разработчики тулкита пишут код чтобы работать на мониторах?

Кстати, угадайте, как в MacOS работает нецелочисленное масштабирование.

Даже не интересно. Я не собираюсь покупать ничего у эппл по другим причинам.

Так, стоп, это мониторы существуют чтобы разработчикам тулкита было удобно писать код, или это наоборот, разработчики тулкита пишут код чтобы работать на мониторах?

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

Даже не интересно. Я не собираюсь покупать ничего у эппл по другим причинам.

Из «не собираюсь покупать» не следует «не интересно». Ну как хотите.

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

А нет. Не сошлись...

Вот допустим если бы GTK3 контролировал хотя бы 51% всего десктопного софта на всех платформах, я бы ещё как то понял необходимость выкинуть ВСЕ созданные до этого мониторы и срочное производство и покупку новых, заточенных исключительно под целочисленное масштабирование.

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

не следует «не интересно»

Следует. Потому что бессмысленно интересоваться тем, что нужно протестировать, но ты точно не будешь.

Вот допустим если бы GTK3 контролировал хотя бы 51% всего десктопного софта на всех платформах, я бы ещё как то понял необходимость выкинуть ВСЕ созданные до этого мониторы и срочное производство и покупку новых, заточенных исключительно под целочисленное масштабирование.

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

При этом это нисколько не противоречит тому, что такие мониторы — всё равно говно, с тулкитом с дробным масштабированием или без.

При этом это нисколько не противоречит тому, что такие мониторы — всё равно говно, с тулкитом с дробным масштабированием или без.

Ну не знаю. Это то же самое, что заявлять что говно все здания с высотой этажа кроме 2300 и 4600мм. Или все машины, с двигателями между 80 и 160 лошадей или весом от 1250 до 2350кг. Ну это просто бред.

А особенно бред потому, что важен не ppi, видимый угол 1 пикселя в зависимости от расстояния до монитора. Идея стандартизовать ppi в целочисленных ступенях просто лишена физико-биологического смысла для человека-пользователя.

Это то же самое, что заявлять что говно все здания с высотой этажа кроме 2300 и 4600мм. Или все машины, с двигателями между 80 и 160 лошадей или весом от 1250 до 2350кг

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

а в случае мониторов — приводят

Нет, ведь мониторы на 120-140ppi это уже стандарт для кучи ноутов, а вин7 (и куча ДЕ в линуксах) отлично на них работали. Так что да, дробное масштабирование в линуксах так себе, но мне кажется сами виноваты потому что сами себе сделали геморроя.

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

Он везде так себе. Прям совсем современные версии Windows с дробным масштабированием не видел, но в 7 были косяки периодически. MacOS вообще не умеет нативно в дробное масштабирование и действует точно так же, как GNOME: масштабирует до ближайшего целого сверху, а затем скейлит вниз композитором до нужного.

В вин7 было всего 3 варианта: 1, 1,25 и 1,5. А вот косяков вообще не было. В вин8+ косяки появились, потом починились, потом снова появились.

Следует. Потому что бессмысленно интересоваться тем, что нужно протестировать, но ты точно не будешь.

Не следует. Для «интересно» достаточно любознательности, желания получения знаний, которые необязательно будут практически применяться. Людям может быть интересна тема чёрных дыр, и вовсе не потому что они собираются отправиться к оной.

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

По факту gtk2 и xterm всё ещё лучше адаптируются к hidpi

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

Если в программе что то захардкожено - тулкит тут в принципе бессилен.

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

Если в программе что то захардкожено - тулкит тут в принципе бессилен.

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

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

А если захардкожены пиксели через какой нибудь «вывести прямоугольник 10х20» в обход тулкита?

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

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

Да встречал изредка. Но тут мы возвращаемся к тому же вопросу: ИЛИ приложение изначально расчитано на масштбаирование, в т.ч. через векторные линии в css, ИЛИ тулкит и ВМ ничерта с этим сделать не смогут - только в лоб растянуть и замылить растр.

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

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

Мы вроде бы уже сошлись на том, что между 96 и 182 ppi есть чёртова туча мониторов, на которых надо как то работать. Короче или рисовать линии в милиметрах, или смириться с тем, что линия толщиной 3,475 пикселя это нормально несмотря на весь полагающийся при этом блюр, радугу и настройки субпиксельного сглаживания.

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

Что мешает увеличивать все размеры в CSS до ближайшего целого? Им CSS вообще для чего? Только чтобы ломать мозг разработчикам тем? Браузеры масштабируют нормально уже сто лет как.

1.5, это нужно в x3 и поделить на 2? Ну… прально, нищеброды должны страдать)

В GTK3 убрали границу вокруг меню, нечувствительную к нажатиям мыши, и её невозможно вернуть обратно.

Смесь из программистов (без знаний про UX), маркетологов (без знаний про UX) и говнодизайнеров (без знаний про UX) абсолютно не в курсе, что эта граница существует не просто так, а имеет свою функцию в работе интерфейса.

Когда правой кнопкой открываешь popup меню, она защищает от того, чтобы случайное смещение мыши не сделало первый пункт меню выделенным, и при отпускании ПКМ он не активировался.

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

Кстати, разрабы Opera до сих пор всё делают правильно.

У них и меню имеет защитный отступ.

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

В GTK3 убрали границу вокруг меню, нечувствительную к нажатиям мыши, и её невозможно вернуть обратно.

Убрали по бокам. Сверху и снизу осталась: https://ibb.co/2yfzsR8 — так что первый пункт меню в безопасности.

Смесь из программистов (без знаний про UX), маркетологов (без знаний про UX) и говнодизайнеров (без знаний про UX) абсолютно не в курсе, что эта граница существует не просто так, а имеет свою функцию в работе интерфейса.

Когда правой кнопкой открываешь popup меню, она защищает от того, чтобы случайное смещение мыши не сделало первый пункт меню выделенным, и при отпускании ПКМ он не активировался.

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

Нужно ли говорить, что в GTK3 popup-меню открываются с отступом от курсора? Наверное, нет — жалко разваливать такой складный аргумент :-)

Ладно, убедил.

Проверил в тунаре.