В Wayland завезли глобальные хоткеи

убоги донельзя

Но архитектурные концепции от NeWS/OpenView были неплохими. Даже хорошими. Даже в NeXT похожие были. И в OS X перешли. Нет, у нас есть теперь офигенная ИННОВАЦИЯ, наконец-то, спустя десятки лет развития, мы ОПЯТЬ предлагаем фигачить битмап в фреймбуфер! Это самое модное и стильное!

жопу рвать и костыли городить

Ну да, ну да. Проверить default route либо забинженый интерфейс теперь так называется. И это на фоне вечного резолва на каждый чих в libc с отвалом по таймауту.

Но архитектурные концепции от NeWS/OpenView были неплохими. Даже хорошими. Даже в NeXT похожие были. И в OS X перешли.

Что именно в них было хорошего?

Нет, у нас есть теперь офигенная ИННОВАЦИЯ, наконец-то, спустя десятки лет развития, мы ОПЯТЬ предлагаем фигачить битмап в фреймбуфер!

Потому что в любом случае к этому всё сходится. Сорян, монитор у тебя принимает вот этот самый битмап и отсылает его тебе прямо в зенки (или чем ты там в него смотришь). Фактически, тут всё сводится к двум вопросам:

1. насколько сильно будет стейт размазан между приложением и сервером?
2. кто будет рендерить всё это в битмап?

В итоге выясняется, что смысла размазывать стейт-то особо и нет. А то так можно дойти до того, чтобы засунуть HTML+CSS движок в дисплейный сервер и рендерить вебговно прямо в нём. Не, ну а чо, PostScript же засунули в NeWS, чойта HTML низзя-та?

Проверить default route либо забинженый интерфейс теперь так называется.

А если нет default route? А если у меня только fe80::/64 в системе и мне это ок?

А если у меня только fe80::/64 в системе и мне это ок?

А ты точно настоящий сварщик? Для этого и не нужно ничего.

А ты точно настоящий сварщик? Для этого и не нужно ничего.

Для этого нужно поднять интерфейсы. Конфиг интерфейсов может быть нестандартным: вланы, мосты, х%№-моё. Предлагаешь проверку этого всего в свой софт пихать? Или, может, всё таки After = network.target проще будет?

Так, а какая разница тогда ему, есть там х%№-моё, или нет? Какая разница с localhost?

засунуть HTML+CSS движок в дисплейный сервер и рендерить вебговно прямо в нём. Не, ну а чо, PostScript же засунули в NeWS, чойта HTML низзя-та?

Так ответ же у тебя - вебговно нельзя, элегантный вектор - можно.

Надо всё через skia писать. И желательно чекбоксы и баттоны только в векторе.

Так ответ же у тебя - вебговно нельзя

Чем вебговно принципиально отличается от postscript?

элегантный вектор - можно.

Зачем? Чем вектор лучше битмапа, учитывая, что дохрена софта всё равно будут битмап слать? Фоточки посмотреть – битмап, в игры поиграть – битмап, киношки посмотреть – тоже битмап, растровые шревты в терминале поставил по старой памяти – и тут сраный битмап вылезает! Никуда от него, проклятого, не деться!

Надо всё через skia писать. И желательно чекбоксы и баттоны только в векторе.

У тебя будет жирный сервер, который всё равно не будет покрывать 100% потребностей. Поэтому вот эти векторные фантазии и оказались выкинуты на помойку истории.

А где линка на срач в обсуждении?

растровые шревты в терминале поставил по старой памяти

Держите наркомана! (простите).

У тебя будет жирный сервер, который всё равно не будет покрывать 100% потребностей.

Или ещё более жирный бутерброд из 100 велосипедов (как сейчас), потому что всё равно

Фоточки посмотреть – битмап,

если поправить их слегка - тотально окружены вектором, битмап только на текстуре, которая масштабируется

в игры поиграть – битмап

или битмап там только в текстурах, остальное - вектор.

Кстати, у меня в KDE движок тем kvantum. Зараза, тоже вектор.

Держите наркомана! (простите).

Ксо жалению, рендеринг шревтов в лялехе всё ещё сосёт.

У тебя будет жирный сервер, который всё равно не будет покрывать 100% потребностей.

Или ещё более жирный бутерброд из 100 велосипедов (как сейчас), потому что всё равно

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

или битмап там только в текстурах, остальное - вектор.

Сервер об этом не знает, потому что рендерингом занимается движок внутри. Для сервера от игр приходит только битмап. Или ты хочешь предложить ещё и какой-нибудь Unreal Engine прямо в сервер встроить?

Кстати, у меня в KDE движок тем kvantum. Зараза, тоже вектор.

Аналогично. Kvantum рендерит всё сам, сервер получает битмап. Зачем этот рендеринг перемещать внутрь сервера? Непонятно.

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

В озабоченных лицензиями системах типа дебиана и корпоратских дистрах вроде шапки всё так.

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

и именно поэтому клиенты могут пережить смерть композитора

А есть хоть один композитор, который так умеет? А то я слышал, что вроде да, может, а так чтобы killall $COMPOSITORNAME & $COMPOSITOR и оно всё подхватилось и продолжило работать, ещё не видел.

Так, дизайн графической подсистемы макос нам не известен

GNUStep - аналог очень ранней версии современной макоси.

простой сервер

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

Зачем этот рендеринг перемещать внутрь сервера?

Аналогично, зачем современные FS - будущее за exfat!

Так, дизайн графической подсистемы макос нам не известен.

Ещё как известен. Как и вендовой. Исходники тут не нужны.

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

Сорян, не моя вина что у них терминология такая.

Зачем этот рендеринг перемещать внутрь сервера?

Аналогично, зачем современные FS - будущее за exfat!

Когда аргументы кончились, можно и передёрнуть. Поддержу!

и именно поэтому клиенты могут пережить смерть композитора

А есть хоть один композитор, который так умеет?

Qt-шный софт под KDE может уже года три как. Возможно, не только под KDE.

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

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

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

Я не столько про прогу, сколько про тулкит

GTK4 does not support seamlessly reconnecting to a Wayland compositor if the connection drops or the compositor crashes

Выходит Qt 6.6+ поддерживают, даже XWayland пишут что поддерживает в каком-то виде, а гномосеки опять обделались.

Не скажу как должно быть, это надо очень много думать про архитектуру. Но те кто проектировал вяленд, могли бы и подумать под механизмом который бы не зависел от реализации в тулките. В идеале бы вообще иметь возможность передавать приложения от композитора к композитору на лету. Про выживание после смерти и способы приложениям не помирать, ещё иксах были какие-то костыли(типа xpra).

Qt-шный софт под KDE может у

И правда, ну зачем это тянуть в композитор/сервер/чёрта в ступе, ведь так хорошо на клиенте!

GTK4 does not support seamlessly reconnecting to a Wayland compositor i

А он вообще с композиторами, отличными от mutter, нормально работает?

У меня Hyprland и каких то проблем с приложениями на GTK4 я не замечал. Стараюсь по возможности их предпочитать GTK3, ибо завезли GPU ускорение отрисовки в 4 версии вроде как.

ибо завезли GPU ускорение отрисовки в 4 версии вроде как.

Странно, как же Xaw без gpu ускорения так быстро отрисовываются!

Странно, как же Xaw без gpu ускорения так быстро отрисовываются!

Я не говорю, что это панацея. Просто мне приятнее, когда на GPU. Считай, что это такая мания быть на bleeding edge. Мне вот жаль, что автор Hyprland не хочет(говорит что ничего не даст) на вулкан переходить(OpenGL фу и устарело). Это же технологичнее и современнее.

И правда, ну зачем это тянуть в композитор/сервер/чёрта в ступе, ведь так хорошо на клиенте!

В иксах, вялянде и вообще любой оконной системе клиенты подключаются к серверу, не сервер к клиентам. Соответственно, переподключение должны инициировать тоже они.

гномосеки опять обделались

Тебя что-то удивляет?

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

Да, по-хорошему это надо засунуть в какой-нибудь libwayland, но есть нюанс. Нюанс состоит в том, что надо получить новый фреймбуфер от композитора (старый-то сдох), переинициализировать OpenGL/Vulkan контекст (опять же, старый сдох), перерисовать окошки заново и заново зарегистрировать всю бурду типа глобальных хоткеев. Тут особо никак иначе это не сделать. Можно сохранять весь стейт композитора, но если он сдох от какого-нибудь сегфолта, то расчитывать на консистентность и актуальность этого стейта – весьма тупая идея, так можно и вагон глюков на ровном месте поймать: например, прога зарегистрировала хоткей, композитор сдох, перезагрузился и «забыл» про него.

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

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

Тогда я бы вернулся на винду. Не хватало еще мониторы подбирать под убогую систему скалирования картинки.

Не хватало еще мониторы подбирать под убогую систему скалирования картинки.

Куда уж хуже чем оригинальный вариант целочисленного масштабирования в Wayland.

До гномерского варианта мне дела нет, но на вейленде и даже иксах с этим ситуация лучше.

Соответственно, переподключение должны инициировать тоже они.

Как это мешает дать им жёсткий API? Вплоть до магического синтаксического сахара или что там можно сделать, да тупо до LD_PRELOAD можно довести.

Как это мешает дать им жёсткий API?

Этот API будет делать внутри себя примерно половину того, что делают тулкиты. Фактически, ты хочешь просто стандартный GUI-тулкит под Linux/Wayland. Было бы неплохо, соглашусь, но за 35 лет люнексоеды так и не родили его.

Так идеологи wayland форсят идею, что это не нужно. И тут именно важно, чтобы этот «GUI-тулкит» занимался только базовыми вещами gui, а остальное пускай делают gtk, Qt... Что-то в стиле как делает wx поверх более низкоуровневых вещей. Т.е. и Qt, и GTK должны поверх условной Skia работать.

Так идеологи wayland форсят идею, что это не нужно.

Я не уверен, что у них есть какие-то идеи и они их форсят кому-то, потому как в среднем черепные коробки там страдают от переизбытка наполнителя для кошачьих туалетов. Но выкинуть из иксов весь мусор было бы довольно годной инициативой лет 20 назад. Yserver – это примерно то что нужно, только он появился на 20 лет слишком поздно.

И тут именно важно, чтобы этот «GUI-тулкит» занимался только базовыми вещами gui, а остальное пускай делают gtk, Qt… Что-то в стиле как делает wx поверх более низкоуровневых вещей.

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

Т.е. и Qt, и GTK должны поверх условной Skia работать.

Ты зациклился на этой Skia зачем-то, и вот я не очень понимаю зачем. Если под капотом у Qt и GTK будет одна и та же библиотека рендеринга, не изменится ровно нихрена.

Ещё как известен. Как и вендовой. Исходники тут не нужны.

Дизайн f-22 raptor тоже известен. Он весь налицо. Бери и делай. Но, почему-то без исходников не получится

Ещё как известен. Как и вендовой. Исходники тут не нужны.

Дизайн f-22 raptor тоже известен. Он весь налицо. Бери и делай. Но, почему-то без исходников не получится

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

Рабочую макось я вот прямо сейчас могу скачать с торрентов и запустить в эмуляторе или даже – хоть и изрядно потрахавшись – на голом железе, после чего при желании расковырять внутренние компоненты, посмотреть кто там с кем общается и какую роль вполняет и так далее. F-22 Raptor я могу… а нет, я не могу.

странный ты
останови mydaemon.socket или вообще выключи его автозагрузку, если такой функционал вовсе не требуется, оставь только mydaemon.service

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

Можете. Но, подобный реверс-инжиниринг требует овердохрена денег и высококлассных специалистов. И тут мы натыкаемся на проблему реактоси: кто может сделать такую работу, им это неинтересно, а денег fsf на это не даст. Кому это интересно, не могут. Вот, вам интересно - делайте! Качайте, трахайтесь, ковыряйте

Можете. Но, подобный реверс-инжиниринг требует овердохрена денег и высококлассных специалистов.

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

мы натыкаемся на проблему реактоси:

Нет, не натыкаемся.

Иксы из него сделают, тогда заживём

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

Копируйте, раз вам ничего не мешает