В Haiku появилась реализация Wayland с возможностью запуска GTK-приложений

С системным API для GUI код как раз упрощается.

Нет.

Системный API либо устаревает и не содержит нового, либо развивается и имеет разные версии с разными фичами. И даже сложно сказать, какой вариант хуже.

Если я пишу программу в 1993м и у меня 8битная палитра, преобразования координат вида window/viewport (т.е. translate + scale), никаких градиентов и альфы, то я и использую библиотеку такого уровня. Если пишу в 2000м, то у меня и 24битный цвет, и матрицы и альфа, и я использую библиотеку соответствующую. И обе библиотеки работают с буфером окна, и новой не надо париться на тему, запущена она на windows xp или на 95, и надо всё эмулировать.

В чём проблема добавлять новые функции к имеющемуся api?

Че, похоже гайка медленно но неотвратимо приближает линуксокапец

линукс будет также помирать как и оффтопик

Линукс и так едва едва дышит.

«Ты не думай что ты лучший, просто ты дешевый»

Вообще-то у всех юниксов есть официальный API и это X11.

Лицо человека который предлагает использовать древний иксохлам типа Xlib/Xm/Xaw в качестве официального API в 2022 вообразили себе?

К счастью в реальности, а не во влажных снах, разработчики выкидывают иксокостыли отовсюду из UNIX’ов, где они раньше были.

Смех и только. X11 официальный API в UNIX, ага. Который сегодня во всех популярных Linux-дистрибутивах вроде Debian, Fedora, RHEL/CentOS Stream, SUSE Enterprise Linux, Ubuntu и др. работает через XWayland-прослойку, а из единственного сертифицированного десктопного UNIX™ его давно выкинули в какой-то отдельный захолустный пакет XQuartz, который для иксовой некрофилии нужно скачивать отдельно с левого сайта.

Официальное мать его API оно такое, бгг.

В чём проблема добавлять новые функции к имеющемуся api?

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

Лицо человека который предлагает использовать древний иксохлам типа Xlib/Xm/Xaw в качестве официального API в 2022 вообразили себе?

Не понял, что именно надо было вообразить. И не понял, при чём тут Xm/Xaw. X11 это протокол, с некоторой натяжкой можно считать что Xlib или Xcb это его референсное библиотечное представление, всё остальное идёт мимо - это уже высокоуровневые штуки, построенные на базе X11 (тулкиты).

Смех и только. X11 официальный API в UNIX, ага. Который сегодня во всех популярных Linux-дистрибутивах вроде Debian, Fedora, RHEL/CentOS Stream, SUSE Enterprise Linux, Ubuntu и др. работает через XWayland-прослойку,

Ну это враньё, в дебиане (11, т.е. последняя версия) у меня никаких xwayland нет и не было, и ставиться они не пытались при апгрейдах релизов. Что там в школо-убунтах или корпо-шапках не знаю.

X11 это протокол, с некоторой натяжкой можно считать что Xlib или Xcb это его референсное библиотечное представление, всё остальное идёт мимо - это уже высокоуровневые штуки, построенные на базе X11 (тулкиты).

К счастью он deprecated и завёрнут в актуальных UNIX-like системах завёрнут в Legacy-обёртки. Выше тут речь шла про системные API и именно поэтому я упомянул Xt => Xm/Xaw как пример того, что иксовая экосистема не смогла родить достойного конкурента WinAPI, Cocoa API или даже сабжевого Haiku API, и все эти Athena Widgets и Motif’ы встретившись с реальностью обвякнув пукнули и остались на свалке истории.

Одной из причин того, что сегодня в UI десктопных Linux-дистрибутивов сущий зоопарк и GUI Toolkit Hell, с прочим идиотизмом в виде шести несовместимых между собой версий Qt и четырёх GTK+, мы обязаны как раз иксовому барахлу, которое не смогло стать прочным фундаментом и опорой для существующих тулкитов.

Ну это враньё, в дебиане (11, т.е. последняя версия) у меня никаких xwayland нет и не было, и ставиться они не пытались при апгрейдах релизов.

Десктопный Debian давным-давно предлагает по умолчанию к использованию GNOME DE под Wayland-сеансом: https://www.opennet.ru/opennews/art.shtml?num=40659

Одной из причин того, что сегодня в UI десктопных Linux-дистрибутивов сущий зоопарк и GUI Toolkit Hell, с прочим идиотизмом в виде шести несовместимых между собой версий Qt и четырёх GTK+, мы обязаны как раз иксовому барахлу

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

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

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

Почему-то в Windows и macOS проблему устаревания системного API огранично решают и по итогу мы видим лишь улучшения.

Пример из реальной жизни. Берём любое древнее приложение под Windows, написанное с использованием стандартного WinAPI и запускаем его на современном железе со всеми его HiDPI, 4K Retina™ примочками. Можно даже взять вообще экстремальный пример набора Win16-программ 80-ых годов на современной винде:

https://i.imgur.com/wrO4HBs.png | Скриншот за авторством X512

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

Уровень осовремененности и обратной поддержки недостижимый не то что для давно мёртвого иксового копролита в лице Xt/Xaw (Athena Widgets) или Xt/Xm (Motif), но и до относительно недавних Qt 4 и GTK+2 тулкитов, программы на которых теперь обречены навсегда на мыльцо или на подобные косяки отрисовки при их запуске на современных системах:

• https://baat.exlmoto.ru/~exl_lab/pics/vlc_hidpi_fail.jpg
• https://baat.exlmoto.ru/~exl_lab/pics/vlc_hidpi_fail2.jpg
• https://wiki.audacityteam.org/wiki/File:Audacity_gtk2_4k.png

Ну вот ты сам и описал проблему: старые системы. Причём в отличие от твоих прохладных историй я тебе могу реальный пример привести: вечная борьба Microsoft за продвижение нового DirectX. Не смотря на все труды по обеспечению совместимости, обеспечению лёгкого перехода, на рекламу давно уже назревшего апгрейда, реальную пользу от нового API начинают получать примерно к тому времени, когда винду, в которую его добавили, уже пора было на новую менять. Представь, если бы новый DirectX можно было бы прямо на диске с игрой распространять, ставишь на свою старую XP Elden Ring, а инсталлятор сам тебе DirectX 12 устанавливает. Насколько быстрее внедрение технологий бы шло.

Но с графическими API под виндой это невозможно, там всё на драйверную модель завязано, нужно полсистемы менять. А вот в GUI - вполне, бери любую удобную тебе библиотеку, умеющую в растры рисовать, и пользуйся. Но нет, нам не надо, нам подавай одну единственную специальную библиотеку, прибитую гвоздями к системе, чтоб отхватить весь геморрой без какой-либо пользы.

Десктопный Debian давным-давно предлагает по умолчанию к использованию GNOME DE под Wayland-сеансом: https://www.opennet.ru/opennews/art.shtml?num=40659

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

Почему-то в Windows и macOS проблему устаревания системного API огранично решают и по итогу мы видим лишь улучшения.

Про макось не скажу, но под виндой её точно не решают. Начиная с 200х MS забили на развитие одного API и тупо клепают новый к каждой новой их технологии. Я не особо знаток, но сходу назову GDI+, WPF, Direct2D и наверное ещё что-то напилено. Вообще, чисто для примера, в оригинальном GDI была возможность выбрать режим наложения пикселей. Перезапись или битовые and/or/xor. Наверно в старых чёрно-белых так мышиный курсор поверх рисовался. Представляешь себе современное GDI с автоматическим масштабированием, с преобразованиями матрицами, полупрозрачностью и т.п. в котором при этом вывод в режиме xor как-то вменяемо работал?

И что мы тут видим?! А то что в современной системе благодаря тому, что системное API развивается, а не стагнирует или заброшено,

Нет, мы видим совершенно иное. Теоретически можно достать какой-нибудь древний мотиф и добавить в него поддержку hidpi. Хотя бы масштабированием lo-dpi-растра с последующим шарпом или даже какими-нибудь фильтрами, которые в эмуляторах старых приставок используются. Всё что нужно для этого - чтоб кто-то с руками и свободным временем за это взялся. При этом будет совершенно неважно, системный тут API или несистемный. Ну, теоретически, представим что redhat называл бы GTK1 в своё время системным графическим тулкитом, это что, заставило бы их адаптировать этот GTK1 под современные требования? Нет, конечно, точно так же выкинули бы и сказали б апгрейдиться на 3й, если хочешь hidpi.

GDI+, WPF, Direct2D и наверное ещё что-то напилено.

Виндовые WPF и какой-нибудь MFC опираются на примитивы системного WinAPI в своей работе, который бампнули и они получили возможность нормальной работы в 4K. GDI+ насколько я помню может использовать как ускоренный Direct2D, так и обычный программный рендеринг для отрисовки своих примитивов, насколько я помню. То бишь для программ «сверху», которые этот GDI+ используют – безразлично как именно будет он потом ускорен или нет и куда он там выводит свою картинку.

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

Почему в Windows и macOS их разработчики добавили поддержку HiDPI в системные WinAPI и Cocoa API и сохранили совместимость не только вниз, но и вверх, а Red Hat бы не смог провернуть подобное с GTK+?

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

Вопрос без прикола, от человека, кто кодил под офтопик: Win32 (Common controls), GDI, GDI+, Direct2D, WinForms, WPF, UWP - это так выглядит опора на стабильность?

ЗЫ. А вниз уже спрашивали. Не дочитал, соррян.

В системном API появляется новый интерфейс, старый при этом никуда не исчезает

Ну и где этот интерфейс Aero и всё это стекло, которым в своё время все мозги заимели?

а Red Hat бы не смог провернуть подобное с GTK+

Потому что Мак и Вин - единый проект. Т.е. МС может перекодить граф.подстистему (не один раз), выкатить очередной злоездучий фреймворк и снова перелопатить DirectX … но сложить это всё в один «кулёк» и наворотить кучу обвязок над старым API, чтоб это не развалилось нафиг (хотя периодически и забивает, не без этого). Это же всё она сама и делает, для единого продукта.

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

Ну и также, вся эта радость обеспечивается тасканием в системе всех рантаймов, начиная с древних, всех directx, которые там же и т.д. и т.п. С таким же успехом можно и в Linux поставить gtk4/3/2/1 (он собирается на свежей Убунте и даже запускается) и оно заработает.

С таким же успехом можно и в Linux поставить gtk4/3/2/1 (он собирается на свежей Убунте и даже запускается) и оно заработает.

Нет потому что GTK 2, 3, 4 не работают поверх GTK 1, а в Windows весь GUI работает поверх user32/gdi32 API которых не менялись несовместимым образом ещё со времён Windows 1.0.

Так я не про API, а про «работать будет». Работает, тасканием рантаймов за собой. Ну то, что RH/Canonical/Debian/etc. не подрядились их (gtk1/2) таскать, ну соррян.

Можно даже взять вообще экстремальный пример набора Win16-программ 80-ых годов на современной винде

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

Это всё замечательно и отлично. Просто супер для пользователей 16-битных приложений. А можно мне эти все примочки не в 16-битных приложениях, а в приложениях, которые прямо в составе Windows 10 идут? А то там либо очень мелкий текст, либо мыло.

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

Ты же понимаешь, что 16-битные приложения на 64-битной Windows работают через слой эмуляции, да? И что когда речь про современные приложения идёт, имеются в виду такие примеры, как контрольная панель. Уж кто-то, а Microsoft должны бы правильно писать. Но как-то нет.

В итоге вызываются настоящие вызовы user32/gdi32, а не рисование всего самостоятельно как в GTK 2 например. То есть используется родная векторная графика системного тулкита.

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

То есть используется родная векторная графика системного тулкита.

Точно уверен? Вон, «кнопки» в 16-битном калькуляторе какие-то сильно пикселизованные. Сильно сомневаюсь, что в те времена кнопки рисовали битмапами. Скорее всего, они рисуются именно векторными командами. Откуда тогда такие здоровые пиксели? Уж не от масштабирования ли полученного растра? Где делается масштабирование? Прозрачно для пользователя, внутри gdi? Сильно сомневаюсь. Скорее всего это происходит в слое эмуляции, так что это не заслуга совместимости API/ABI.

gdi.exe (не знаю почему EXE, на самом деле оно DLL) был начиная с Windows 1.0.

Вон, «кнопки» в 16-битном калькуляторе какие-то сильно пикселизованные.

Да потому что GDI рисует без сглаживания. Хоть в Windows 1.0, хоть в Windows 11. Для склаживания надо использовать GDI+/Direct2D.

Откуда тогда такие здоровые пиксели? Уж не от масштабирования ли полученного растра?

Это которые кнопки в Paint? Это потому что сами кнопки – растровые картинки и они масштабируются в соответствии даже не DPI, а размером окна.

Где делается масштабирование? Прозрачно для пользователя, внутри gdi?

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

Скорее всего это происходит в слое эмуляции, так что это не заслуга совместимости API/ABI.

Слой эмуляци делает в основном трансляцию 16->32/64 бита, он в итоге вызывает всё те же API.

Виндовые WPF и какой-нибудь MFC опираются на примитивы системного WinAPI в своей работе

Это неправда. MFC - да, это тупо надстройка над USER и GDI, просто на плюсах, а вот GDI+ - это отдельная либа, умеющая то, что GDI не может вообще. Те же градиенты. Т.е. понятно, что GDI у неё мог работать бэкендом, по крайней мере на старых виндах, но, скорее всего, очень ограниченым набором функций. Основная часть функционала стала чисто софтварной, реализованной прямо в GDI+. Но, главное: GDI перестали развивать. Всё. Никто не добавил туда новых функций, чтоб быть хоть и неудобным, но аналогом GDI+, вместо этого предложили оставить помирать как есть, а новый софт писать под новую, несовместимую либу.

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

Википедия не согласна. С её точки зрения всю ускорябельность выкинули из GDI на этапе добавления композитинга в висту, потом в 7ке вернули, но только для блитинга (т.е. копирование прямоугольных областей растра). Хочешь ускорения - вот, новый direct2d.

Почему в Windows и macOS их разработчики добавили поддержку HiDPI в системные WinAPI и Cocoa API и сохранили совместимость не только вниз, но и вверх, а Red Hat бы не смог провернуть подобное с GTK+?

Что значит «не смог»? Не захотел. Средств у них нет, т.е. денег у них не хватает.

Это которые кнопки в Paint?

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

Слой эмуляци делает в основном трансляцию 16->32/64 бита, он в итоге вызывает всё те же API.

Опять-таки, сильно сомневаюсь. Битность разная, так что понадобится не вполне тривиальная трансляция. И если транслятор API это такой признак совместимости, то графическая система Linux прям очень совместима, потому что там можно приложения через WINE запускать. Он же транслирует вызовы.

растровые картинки и они масштабируются в соответствии даже не DPI, а размером окна.

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

HiDPI in OS Haiku

https://i.imgur.com/lYE1a7u.png

А то там либо очень мелкий текст, либо мыло.

Я помню что проблемы с Диспетчером Устройств были, окно у подобных старых приложений было мыльное, но сейчас ведь норм всё.

Линукс и так едва едва дышит.

Так, по-хорошему, и гайка ничем не лучше Linux. Что в ней такого, чего нет в линукс и что может уничтожить оффтопик?

в гайке консистентный и единообразный интерфейс

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

Было бы очень странно в любительской ОС, где всё в добровольно-принудительном порядке рисуется через общий интерфейс графической системы, иметь косяки с отрисовкой шрифтов и вообще UI. Люди занимаются этим проектом в свободное время, для души, а не для решения задач которые «прямо вот вообще всё горит, и нужно прямо сейчас хоть что-то, не важно как уродливо». Там нет особых заморочек с поломкой стороннего ПО. Наверняка они спокойно и системный вызов могут удалить из ядра, не говоря уже о неугодном API каких-то библиотек. Не думаю, что пользователи-разработчики особо запариваются с тем, что какой-то существующий софт перестанет работать. Можно же починить этот софт и перекомпилировать.

При дробном масштабировании шрифты в контрольной панели размытые. Возможно, ты просто привык и уже не замечаешь?

В новой или старой? Их же там две, лол.

Если с Windows 8 ничего не менялось, то я имею в виду старую. Которая выглядит так же, как оная в Windows 7.

Вообще эта муть в шрифтах в Windows очень странная. Там ведь «классические» приложения используют системные виджеты. Визуально простые приложения вроде той же контрольной панели вряд ли занимаются растеризацией текста самостоятельно. Откуда тогда муть?

Диспетчер устройств у тебя тоже мутный?

Вообще эта муть в шрифтах в Windows очень странная.

https://rsdn.org/forum/usability/1407828

https://agg.sourceforge.net/antigrain.com/research/font_rasterization/index.html

Так, по-хорошему, и гайка ничем не лучше Linux. Что в ней такого, чего нет в линукс и что может уничтожить оффтопик?

Скорость работы.

Скорость работы и в линуксе нормальная.

Шрифты в диспетчере устройств нормальные. Иконки мутные, что, в принципе, ожидаемо, но одновременно и не ожидаемо. Возможных масштабов всего четыре (100, 125, 150, 175), но иконки нарисованы только под 100.

Диспетчер устройств был той самой древней WinAPI-программой, которой троллили Microsoft по поводу поддержки HiDPI в Windows 10 долгое время. Раньше там было жуткое мыло:

https://baat.exlmoto.ru/~exl_lab/screens/win10_hidpi_fuckup.png

Но они уже давно это поправили. Что же касается старой «Контрольной панели», за которую (точнее за две их отдельные сущности) Microsoft вполне справедливо получает всю критику и насмешки, так вот, похоже что они решили забить на неё полностью, потому и мыльная.

Кстати я сомневаюсь, что эта контрольная панель про которую ты говоришь, является Pure WinAPI приложением. Ещё во времена Windows 7 или даже Windows XP эта панель представляла собой какую-то химерную НЁХ, с отрисовкой на Embedded Internet Explorer.

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

Да, потому что системные вызовы – не часть публичного ABI также как и в Windows. Программы должны использовать API предоставляемый системными динамическими библиотеками. Также в отличии от Linux/BSD, в Haiku запрещена полностью статическая линковка.

Можно же починить этот софт и перекомпилировать.

В Haiku всё ещё запускается софт от BeOS 20+ летней давности.

Вообще эта муть в шрифтах в Windows очень странная.

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

В Haiku всё ещё запускается софт от BeOS 20+ летней давности.

Справедливости ради, не в 64-битной же версии? Или уже это поправлено?

Скорость работы и в линуксе нормальная.

Чушь. Даже скорость запуска с SD-карты у Гайки выше, чем на том же ноуте с SSD-шника. Практически мгновенная.

Справедливости ради, не в 64-битной же версии?

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

Скорость запуска – не скорость работы. Запиши туда solus, например, и проверь.