Wayland VS Xorg

а вот интерфейс этой IDE, которую он пишет, прямо очень меня впечатлил.

Так эклипс можно похоже настроить. IMHO он им вдохновлялся.

А со сглаживанием хорошо, особенно когда DPI высокий

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

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

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

Как субпиксельное сглаживание на них включать? Рисовать в шрифте? Тогда нужно для всех видов матрицы отрисовывать.

А вот векторные шрифты без замыливания (что аппаратного что программного) на малых размерах символов выглядят весьма так себе.

Это скорее проблема шрифтов, или настроек, в Windows 7 все шрифты на маленьких размерах становились выровненными попиксельно, думаю как раз за счет подсказок описанных выше.

да не нужно никакое масштабирование. В линуксе можно задать размер шрифта. И шрифт будет отрисовываться в комфортном размере как надо. А идея вейландового масштабирования - когда мы htylthbv картинку в FHD а потом вот эту картинку как единое целое растягиваем в 4К - это идиотизм. Как картинку не масштабируй - будет мыло.

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

Зачем, зачем делать активную часть десктопа на мониторах с разным DPI???

Так эклипс можно похоже настроить.

Мы к сожалению не видим насколько у него там клавиатурное управление хорошо отлажено. А это даже важнее внешнего вида.

IMHO он им вдохновлялся.

На мой вкус он там всё же злоупотребляет ярким фоном. Хотя и меньше чем это бывает например в виндах где слепить пользователя максимально ярко-белым фоном и заставлять разглядывать маленькие буковки нарисованные тонкими штрихами считается нормальным. У этого fresh ide хотябы на части скришотов фон окна с кодом достаточно темный синий. Но у других окон всё равно слишком яркий.

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

Кто только будет этим заниматься? Кроме терминуса растра больших размеров то и нет.

У этого fresh ide хотябы на части скришотов фон окна с кодом достаточно темный синий. Но у других окон всё равно слишком яркий.

Зависит от рабочего места. У меня, например, везде лампы вокруг стола(на 30-40Вт светодиодных), поэтому использую светлые темы у IDE и не парюсь.

Сейчас вот такое вот вообще приобрел(пока не установил):

https://avatars.mds.yandex.net/get-mpic/11472827/2a00000193d5b33a28cb19fc4ad4...

вот и я о том же. но у вяленд-боев кажждый раз - а вот как вы будете окошко таскать с нового 4К на старый ЭЛТ Vga 640х480 таскать? Ага, съели - а я могу! И в этом вейланд маркетинг весь.

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

Белый фон это как бумажный лист, приятно читать. Игрался с настройками монитора? У меня яркость на 70 или даже меньше всегда стоит.

опять же вопрос с кде.

Я так пониваю что вы пользуетесь кде в работе? Если да,то можно полюбопытствовать - решению каких именно задач оно помогает? В чем преимущество перед куда менее жручими до процессора и памяти обычными иксовыми WM ? Если в корпораты в этот монстрище вкладываются - значит должны же быть у него какие-то значимые плюсы?

Кроме терминуса растра больших размеров то и нет.

Ну а чем он вам не нравится то?

Но мелко очень на 4К мониторе

И это сейчас «штатная» беда чуть ли не всего софта на больших мониторах:(

Я так пониваю что вы пользуетесь кде в работе

Чур меня - кде конечно сильно лучше и эстетичнее чем гном, но такой же жручий монстр. Мате и крыса наше все.

Если в корпораты в этот монстрище вкладываются

Корпорасты вкладываются в Qt - а Qt это единственный вменяемый способ разрабатывать кроссплатформенный софт, в том числе коммерческий.

Он на любителя, и подходит только для терминала. Да и зачем страдать с растром при высокой плотности пикселей непонятно. Даже тот же терминус не во всех размерах съедобен, где-то автор откровенно схалтурил. Произвольно подстраивать размер с ним не получится. С другими шрифтами ещё печальнее, там обычно пара мелких размеров юзабельны. И то, проектировались они как правило под 72 dpi. Так что смотрятся просто фигово везде.

DPI очень разный бывает, и шрифты нужны разного размера.

Да, это так. Но что мешает нарисовать шрифты под все наиболее употребительные DPI? Не так их их много,тем более думаю что отличия в +/-5 dpi и заметны не будут. Когда-то,лет тридцать назад, основным аргументом было слишком большое занимаемое шрифтами на диске место. Что сейчас совсем не актуально. Тем более что все шрифты под все DPI и не надо у себя на диске держать,а только под свое значение DPI и только нужные шрифты.

Как субпиксельное сглаживание на них включать?

Зачем вообще сглаживать,т.е.замыливать, шрифт если он идеально прорисован под размер знакоместа? При этом еще и dpi достаточно высокий чтобы символы не были слишком квадратными. Сглаживание - само по себе костыль,сделаный для того чтобы скрыть дефекты преобразования вектроных шрифтов в растр на мониторах с очень низким dpi. Если этих дефектов не будет то и сглаживать будет нечего. Да и мониторов с 75dpi сейчас уже почти не встретишь,разве что на кассовых аппаратах каких-нибудь или может терминалах по продаже билетов.

Но что мешает нарисовать шрифты под все наиболее употребительные DPI?

Ну во времена HD барахла это имело практический смысл. ВЕкторные шрифты по любому попадали под сглаживание а сглаживание на говномониторах древности давало адовое мыло и заставляло глаза вытекать - и приходилось шаманить с растровыми шрифтами. На современных 3K-4K мониторах эта проблема ушла. До тех пор пока нам не начали впендюривать дробное масшабирование и прочие «ништяки» вяленого. Благо пока их можно выключить.

да не нужно никакое масштабирование. В линуксе можно задать размер шрифта.

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

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

Нет, это не дефолт, в обычных релизах выключено, смотрел в about:support.

при идее «перетаскивания» окошка так что половина тут половина там

А зачем вообще так делать - «половина тут половина там»? Какую практическую задачу решает такое расположение окна? Если я нажимаю хоткей «отправить это окно на второй workspace»(который на втором мониторе) то оно пропадает на первом мониторе и появляется на втором. Всё. Никаких «половина тут половина там». С двухмониторными конфигурациями я начал экспериментировать еще в начале двухтысячных когда цены на мониторы стали такое «буржуйство» позволять. И всегда это у меня работало именно так. В Иксах конечно. Вот размер окна и соответственно текста в нем - да, на разных мониторах мог отличаться. И при сильном различии dpi мониторов это могло создавать некоторое неудобство. Но вообще-то под двухмониторные конфигурации надо бы подбирать мониторы с близким dpi - тогда такого не будет. Или если уж они разные то заранее в настройках WM привязывать открытие разных окон к разным мониторам и уже под них содержимое этих окон настраивать.

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

Увы - далеко не только они этим страдают :(

Кто только будет этим заниматься?

Раньше как-то находились. У меня например в коллекции несколько десятков растровых шрифтов собрано с миру по нитке еще чуть ли не с 90х годов - употребляются для экранов всяких микроконтроллерных поделок. Но да, там по-моему самый большой 24 пикселей по высоте. Вообще порыться надо будет в своих архивах,может и больше найдутся. Вот что у них с лицензиями - понятия не имею. Вот это у меня в Иксы подцеплено:

10x20d.pcf.gz
12x24d.pcf.gz
5x7d.pcf.gz
6x10d.pcf.gz
6x13Bd.pcf.gz
6x13d.pcf.gz
7x13Bd.pcf.gz
7x13d.pcf.gz
7x14Bd.pcf.gz
7x14d.pcf.gz
8x13Bd.pcf.gz
8x13d.pcf.gz
8x16d.pcf.gz
9x15Bd.pcf.gz
9x15d.pcf.gz
courB08d.pcf.gz
courB10d.pcf.gz
courB12d.pcf.gz
courB14d.pcf.gz
courB18d.pcf.gz
courB24d.pcf.gz
courBO08d.pcf.gz
courBO10d.pcf.gz
courBO12d.pcf.gz
courBO14d.pcf.gz
courBO18d.pcf.gz
courBO24d.pcf.gz
courO08d.pcf.gz
courO10d.pcf.gz
courO12d.pcf.gz
courO14d.pcf.gz
courO18d.pcf.gz
courO24d.pcf.gz
courR08d.pcf.gz
courR10d.pcf.gz
courR12d.pcf.gz
courR14d.pcf.gz
courR18d.pcf.gz
courR24d.pcf.gz
fonts.dir
fonts.scale
helvB08d.pcf.gz
helvB10d.pcf.gz
helvB12d.pcf.gz
helvB14d.pcf.gz
helvB18d.pcf.gz
helvB24d.pcf.gz
helvBO08d.pcf.gz
helvBO10d.pcf.gz
helvBO12d.pcf.gz
helvBO14d.pcf.gz
helvBO18d.pcf.gz
helvBO24d.pcf.gz
helvO08d.pcf.gz
helvO10d.pcf.gz
helvO12d.pcf.gz
helvO14d.pcf.gz
helvO18d.pcf.gz
helvO24d.pcf.gz
helvR08d.pcf.gz
helvR10d.pcf.gz
helvR12d.pcf.gz
helvR14d.pcf.gz
helvR18d.pcf.gz
helvR24d.pcf.gz
ibm-vio-10x18-b-cp866-r.pcf.gz
ibm-vio-10x18-bi-cp866-r.pcf.gz
ibm-vio-10x18-i-cp866-r.pcf.gz
ibm-vio-10x18-r-cp866-r.pcf.gz
ibm-vio-12x16-b-cp866-r.pcf.gz
ibm-vio-12x16-bi-cp866-r.pcf.gz
ibm-vio-12x16-i-cp866-r.pcf.gz
ibm-vio-12x16-r-cp866-r.pcf.gz
ibm-vio-12x20-b-cp866-r.pcf.gz
ibm-vio-12x20-bi-cp866-r.pcf.gz
ibm-vio-12x20-i-cp866-r.pcf.gz
ibm-vio-12x20-r-cp866-r.pcf.gz
ibm-vio-12x22-bi-cp866-r.pcf.gz
ibm-vio-12x22-i-cp866-r.pcf.gz
ibm-vio-12x22-r-cp866-r.pcf.gz
ibm-vio-12x30-b-cp866-r.pcf.gz
ibm-vio-12x30-bi-cp866-r.pcf.gz
ibm-vio-12x30-i-cp866-r.pcf.gz
ibm-vio-12x30-r-cp866-r.pcf.gz
ibm-vio-5x12-b-cp866-r.pcf.gz
ibm-vio-5x12-bi-cp866-r.pcf.gz
ibm-vio-5x12-i-cp866-r.pcf.gz
ibm-vio-5x12-r-cp866-r.pcf.gz
ibm-vio-6x14-b-cp866-r.pcf.gz
ibm-vio-6x14-bi-cp866-r.pcf.gz
ibm-vio-6x14-i-cp866-r.pcf.gz
ibm-vio-6x14-r-cp866-r.pcf.gz
ibm-vio-7x15-b-cp866-r.pcf.gz
ibm-vio-7x15-bi-cp866-r.pcf.gz
ibm-vio-7x15-i-cp866-r.pcf.gz
ibm-vio-7x15-r-cp866-r.pcf.gz
ibm-vio-7x25-b-cp866-r.pcf.gz
ibm-vio-7x25-bi-cp866-r.pcf.gz
ibm-vio-7x25-i-cp866-r.pcf.gz
ibm-vio-7x25-r-cp866-r.pcf.gz
ibm-vio-8x10-b-cp866-r.pcf.gz
ibm-vio-8x10-bi-cp866-r.pcf.gz
ibm-vio-8x10-i-cp866-r.pcf.gz
ibm-vio-8x10-r-cp866-r.pcf.gz
ibm-vio-8x12-b-cp866-r.pcf.gz
ibm-vio-8x12-bi-cp866-r.pcf.gz
ibm-vio-8x12-i-cp866-r.pcf.gz
ibm-vio-8x12-r-cp866-r.pcf.gz
ibm-vio-8x14-b-cp866-r.pcf.gz
ibm-vio-8x14-bi-cp866-r.pcf.gz
ibm-vio-8x14-i-cp866-r.pcf.gz
ibm-vio-8x14-r-cp866-r.pcf.gz
ibm-vio-8x16-b-cp866-r.pcf.gz
ibm-vio-8x16-bi-cp866-r.pcf.gz
ibm-vio-8x16-i-cp866-r.pcf.gz
ibm-vio-8x16-r-cp866-r.pcf.gz
ibm-vio-8x18-b-cp866-r.pcf.gz
ibm-vio-8x18-bi-cp866-r.pcf.gz
ibm-vio-8x18-i-cp866-r.pcf.gz
ibm-vio-8x18-r-cp866-r.pcf.gz
luBIS08d.pcf.gz
luBIS10d.pcf.gz
luBIS12d.pcf.gz
luBIS14d.pcf.gz
luBIS18d.pcf.gz
luBIS19d.pcf.gz
luBIS24d.pcf.gz
luBS08d.pcf.gz
luBS10d.pcf.gz
luBS12d.pcf.gz
luBS14d.pcf.gz
luBS18d.pcf.gz
luBS19d.pcf.gz
luBS24d.pcf.gz
luIS08d.pcf.gz
luIS10d.pcf.gz
luIS12d.pcf.gz
luIS14d.pcf.gz
luIS18d.pcf.gz
luIS19d.pcf.gz
luIS24d.pcf.gz
luRS08d.pcf.gz
luRS10d.pcf.gz
luRS12d.pcf.gz
luRS14d.pcf.gz
luRS18d.pcf.gz
luRS19d.pcf.gz
luRS24d.pcf.gz
lutBS08d.pcf.gz
lutBS10d.pcf.gz
lutBS12d.pcf.gz
lutBS14d.pcf.gz
lutBS18d.pcf.gz
lutBS19d.pcf.gz
lutBS24d.pcf.gz
lutRS08d.pcf.gz
lutRS10d.pcf.gz
lutRS12d.pcf.gz
lutRS14d.pcf.gz
lutRS18d.pcf.gz
lutRS19d.pcf.gz
lutRS24d.pcf.gz
nil2d.pcf.gz
timB08d.pcf.gz
timB10d.pcf.gz
timB12d.pcf.gz
timB14d.pcf.gz
timB18d.pcf.gz
timB24d.pcf.gz
timBI08d.pcf.gz
timBI10d.pcf.gz
timBI12d.pcf.gz
timBI14d.pcf.gz
timBI18d.pcf.gz
timBI24d.pcf.gz
timI08d.pcf.gz
timI10d.pcf.gz
timI12d.pcf.gz
timI14d.pcf.gz
timI18d.pcf.gz
timI24d.pcf.gz
timR08d.pcf.gz
timR10d.pcf.gz
timR12d.pcf.gz
timR14d.pcf.gz
timR18d.pcf.gz
timR24d.pcf.gz
vga10x20-cp866.pcf.gz

В линуксе можно задать размер шрифта. И шрифт будет отрисовываться в комфортном размере как надо.

Никогда не было юзабильно, так как поля и элементы ui не масштабировались вместе с этим нормально.

…вейландового масштабирования - когда мы htylthbv картинку в FHD а потом вот эту картинку как единое целое растягиваем в 4К…

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

Вот дробное масштабирование - эталонное ненужно.

Недостатков нет, а современные железки без него использовать невозможно (27" и 32" 4k).

Никогда не было юзабильно, так как поля и элементы ui не масштабировались вместе с этим нормально.

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

использовать невозможно (27" и 32" 4k).

Ты это говоришь человеку с 10" 2.2К(GPD) и 14.6" 3.5К (Honor)

Зависит от рабочего места.У меня, например, везде лампы вокруг стола

Возможно еще и от привычек и от свойств глаз. Для меня слишком яркий свет утомителен даже если это просто слишком солнечный день на улице - летом если не в темных очках то постоянно жмурюсь. А уж от виндового ярко белого фона и «тонких» буковок - реально слёзы из глаз через час и ощутимая резь в глазах. При этом на темный линуксовый экран регулярно смотрю часов по 12 и ничего. Глаза по сей день позволяют в магазине прочитать состав на упаковках с едой не пользуясь лупой(хотя вдаль зрение всю жизнь было не идеальным).

Белый фон это как бумажный лист

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

У меня яркость на 70

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

Надо было Xt концепцию развивать, но wayland ввёл догму, что он протокол, а тулкиты рисуют шрифты сами. БУГАГА.

Сделали бы хотя бы спецификацию canvas и ui виджетов, уже лучше было бы.

Да ладно. Отлично поля масштабируются.

Ничего подобного и что важнее - геморрой на пустом месте. У этого метода нет никаких преимуществ.

Ты это говоришь человеку с 10" 2.2К(GPD) и 14.6" 3.5К (Honor)

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

А с 4k 27" x2 - уже слишком крупно и не эффективно, но x1 даже на 32" слишком мелко.

Недостатков нет, а современные железки без него использовать невозможно (27" и 32" 4k).

На 27" 200% вполне нормально. Немного крупнее, чем на 24", но даже если мониторы рядом, не сильно заметно.

Когда-то,лет тридцать назад, основным аргументом было слишком большое занимаемое шрифтами на диске место. Что сейчас совсем не актуально.

У меня шрифты 1 гб занимают, в растре наверное будут все 10 гб %)

Но ты забываешь про размеры шрифта. Они могут быть условно от 8 до 52.

Как субпиксельное сглаживание на них включать?

Зачем вообще сглаживать,т.е.замыливать, шрифт если он идеально прорисован под размер знакоместа?

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

Да и мониторов с 75dpi сейчас уже почти не встретишь

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

Чур меня

Пардон,значит я неправильно понял. Сам уже много лет пользуюсь сильно перенастроенным под себя IceWM и тоже не могу понять зачем вообще нужны монстры типа KDE и Гнома. Именно с точки зрения - решение каких задач они облегчают,а не абстрактной «красоты». Мне на рабочем месте эта абстрактная «красота» не нужна.

Qt это единственный вменяемый способ разрабатывать кроссплатформенный софт

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

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

Страдать - это про векторные шрифты в малых размерах. Чтобы не страдать - dpi на мониторе должно быть за 200. А это пока что весьма не часто встречается у обычных пользователей.

придется пошаманить.Не так уж много в принципе программ которые используются

Согласен. Шаманю. Но удивляет почему авторы софта занижают размер шрифта,создавая нагрузку на глаза пользователей. Лучше бы завышали. Тогда на современных мониторах с высоким dpi было бы сразу нормально,а шаманят пусть те у кого 1360х768 и около того.

На 27" 200% вполне нормально.

Но с 175-180% удобнее и начинаешь получать преимущество от покупки большого экрана с высоким разрешением. А на 32" x2 - совсем печально.

но wayland ввёл догму

Я уже где-то выше писал,что сегодняшние Иксы весьма существенно отличаются от тех Иксов которые я впервые увидел тридцать лет назад. Также и wayland со временем (10-20 лет) допилят до вполне юзабельного состояния несмотря на «догмы». Основная проблема в том,что сейчас никто не знает «как правильно». Остается только путь научного тыка.

У меня шрифты 1 гб занимают

А зачем вам в работе столько шрифтов? Вы полиграфист?

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

#include <dlfcn.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
/*
   Devoted to Cyril Slobin for his excellent works in area
   of Russification

   Copyright (C) 2002 by V. Wagner

   Собирается командой  gcc -o xfontdump.so -shared -fPIC xfontdump.c

   Далее исследуемая программа вызывается посредством

   LD_PRELOAD=xfontdump.so program

 */
void report(const char *function, const char *name);
XFontStruct *(*RealLoadQueryFont) (Display *display, const char* name);
Font (*RealLoadFont) (Display *display, const char *name);

Display* XOpenDisplay( const char* display_name)
    {
      void * handle=dlopen("libX11.so.6", RTLD_NOW | RTLD_GLOBAL);
      void *(*RealOpenDisplay)(const char*);
      if (!handle) exit(127);
      RealOpenDisplay=dlsym(handle, "XOpenDisplay");
      RealLoadQueryFont=dlsym(handle, "XLoadQueryFont");
      RealLoadFont=dlsym(handle,"XLoadFont");
      return (*RealOpenDisplay)(display_name);
    }

XFontStruct *XLoadQueryFont (Display *display, _Xconst char* name)
    {
      report("XLoadQueryFont",name);
      return (*RealLoadQueryFont) (display, name);
    }

Font XLoadFont (Display *display, _Xconst char *name)
    {
      report("XLoadFont",name);
      return (*RealLoadFont) (display, name);
}

void report (const char *function,const char *name)
    {
       char buffer[1024];
       strcpy(buffer,function);
       strcat(buffer,": ");
       strcat(buffer,name);
       strcat(buffer,"\n");
       write(2,buffer,strlen(buffer));
    }

от этого при неправильной настройки появляется радуга

А как вообще понять - пытаются ли Иксы использовать это субпиксельное сглаживание или нет? Результат включения/выключения aliasing в fonts.conf - хорошо видно,а вот «радуги» как-то никогда не видел. Или внимания не обращал. И хорошего макрообъектива для фотоаппарата у меня увы нет чтобы сфотографировать экран с действительно большим увеличением:(

размеры шрифта. Они могут быть условно от 8 до 52.

В больших размерах растровые шрифты и не нужны. Там уже и векторные в растр нормально преобразуются. Я о тех которыми рисуются меню и диалоги в программах,а там как раз именно что достаточно маленькие размеры. И их немного. Где-то до пары десятков пикселей по высоте,может чуть больше. Но точно не 52 и около. Кстати,в древних виндах так и было - меню и диалоги рисовались растровыми шрифтами,а тексты на лазерный принтер с его 300dpi выводились векторными.

в древних виндах так и было - меню и диалоги рисовались

В gtk1 и Qt1 тоже. И в более старших некоторых.

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

Скорее всего от привычек. Я всю жизнь почти проработал в светлых офисах и в VisualStudio со светлой темой. Я и дома делаю себе, чтобы как в офисе было, ярко. Но вот ЛОР люблю танго, и если вебню какую программировать приходится, то беру темную тему vscode. Т.е. для C\C++ мне только со светлой темой комфортно, а для вебни только с тёмной. Вот таки завороты психики.

Думаю что просто самый разрекламированный. Так-то кросплатформенных графических библиотек и без него есть. Вон я выше хотябы Nuklear упоминал.

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

Для меня комфортны тёмные темы при яркости монитора = 15 (пятнадцать), при яркости = 70 и светлой теме у меня бы глаза лопнули.

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

Так что реально альтернативы Qt в этом плане нет - Qt это не просто интерфейс, Qt - это поддержка сетевых протоколов, интерфейсов, медиа-форматов различных - причем ты можешь писать прогу для Qt и она - ну если конечно ты сам не используешь OS-specific вызовы - заведется на любой платформе на кторой есть Qt с минимальными для тебя усилиями. Например для открытия картинок надо тащить какую-нибудь jpeg библиотеку с собой, или в своем коде делать ветвления на то а что там у нас доступно на андроиде, на макосе, на линуксе, на бсд - ты просто пишешь на Qt. А какая там ОС и какой движок - это за тебя сделали в Qt. И проблем с лицензиями нет - делаешь GPL - продукт - велкам, делаешь коммерческий - вот тебе коммерческая лицензия и нет у тебя никакой обязянности открывать свой код. Есть встроенные девелоперские тулзы, обучение, документация профессиональная, поддержка. А это все для корпраций абсолютно необходимо. Корпорации не будут использовать софт васяна - даже если васян гений то просто тот факт что васян может завтра сказать а ну вас всех мне надоело и улететь в тай курить траву, или там еще чего. Для корпораций критически важно чтобы за продуктом стояла компания с приличным штатом , надежным положением и репутацией. Да - корпрация може у генияального васяна выкупить права на софт и начать его самостоятельное развитие и поддержку - но только так.

Не могу переваривать темные темы. пару раз пытался - не получилось.

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

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

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

ты можешь писать прогу для Qt

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

куча страниц веба светлые

Я взял браузер Vivaldi,покрутил ему собственные настройки и добавил addon DarkReader. От бьющих по глазам белых страниц избавился полностью. Единственный дефект который заметил - это математические формулы в Википедии иногда показываются как черные на темном фоне. Но этот Даркридер - штука сама по себе капризная. Пришлось несколько его версий перепробовать пока нашел работающую конекретно с используемой мной версией Вивалди. А сейчас вот хотел версию в About посмотреть,нажимаю на его иконку,а он loading please wait и за полминуты wait ничего не произошло. Хотя функция борьбы с белым цветом работает нормально. Ну и фиг с ним. Всё равно на конкретно этом компе в ближайший год ничего перенастраивать в браузере не собираюсь - отображение страниц устраивает.

А уровень сложности QT такой что сам хрен приделаешь. Оно же насквозь плюсовое.

Но в том-то и дело что НЕ можешь если ты - не корпорация.

Я, не будучи корпорацией, написал в одну каску, довольно сложную софтину на заказ. Написал на кутях. По факту, заняло 1,5 человеко-месяца(работал по вечерам пол года). Учитывая, что мне нужно было и с камерой работать и читать\писать графические форматы, без кутей, я бы долбался сильно больше, по крайней мере если бы захотел кроссплатформы.

В кутях на мой взгляд 2 проблемы:

1. Нестабильность. Часто в новых версиях ломают то, что отлично работало в предыдущих.

2. Довольно убогий редактор форм. Ну по крайней мере если сравнивать с тем что у мелкософта в дотнете\винформах.

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

Как раз подобный толстый софт всегда абстрагируется от библиотек Qt, никто не опирается на них. Telegram от Qt вообще мало что использует, виджеты они сами пеинтят, на других платформах не используют. Если взять совсем монстров, типа хромиума, то им вообще все равно, для одной платформы gtk, для другой другое.

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

Например для открытия картинок надо тащить какую-нибудь jpeg библиотеку с собой

Есть много библиотек для обработки изображений. Некоторые намного лучше. В крупном ПО код какого нибудь libimage может не занять и процента.

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

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

Вон uTox вообще без тулкита написан. Видеозвонки, чаты, пересылка изображений есть. Всякие анимации и видео добавить не проблема. https://upload.wikimedia.org/wikipedia/commons/8/8d/UTox-screenshot.png

Ты писал на заказ, тут есть проблемы, одну из них ты сам описал:

1. Нестабильность. Часто в новых версиях ломают то, что отлично работало в предыдущих.

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

Мне немного проще было. У меня основная ОС заказчика - венда, а кроссплатформа, это мой личный загон. А на венде всё просто, положил дллки кутешные в каталог с екзкшником и ближайшие лет 5-10 оно будет работать.

PS: Правда на лтс версию 6.8(6.8.2) я всё же перевёл(разрабатывал на 6.6) под конец работы.