GTK 4 вышел

Давайте юзеру счёты дадим, пусть на них всё делает.

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

А тут поподробнее расскажите про кривость и убогость

Кривость и убогость заключается в

1. Завязке на традиционную модель рабочего стола с абсолютными координатами. Эта модель ломается уже при добавлении воркспейсов, в ней не реализовать никакую логику. Для работы с убогой моделью программам была дана свобода управлять своими окнами (передвигать, растягивать, …), и не только ими. Об этом следующий пункт.
2. Свободе приложений управлять собой. Приложениями должна управлять операционная система (под управлением пользователя), или пользователь напрямую. Ни одно приложение не должно рассчитывать на то, что его реквесты будут выполняться, оно может просить – но отказ должен быть нормой. Я не против чтения всех клавиш, нажатых пользователем – но только с явного разрешения пользователя. Я не против абсолютных координат – если система умеет в это, не особо против даже перемещения окон – пока пользователь на это согласен. Традиционная модель никак не считается с мнением юзера – если окно решило открыться в фуллскрине, и оно откроется, и никак пользователь на это не повлияет. Может свернуть, но приложение может просто принудительно опять развернуть его в фуллскрин.

Все это реализуемо под Wayland. Я вижу порталы гигантским шагом навстречу такому десктопу, который можно будет гибко настраивать и удобно использовать. Я нигде не говорю про тайловость и CSD/SSD, я не говорю про текстовые конфиги/gui настройки, и так далее, это все не имеет никакого значения. Я говорю про принципиальную модель взаимодействия юзер-система-приложения.

Еще в GTK3 завезли поддержку Wayland.

Для нетайловых WM модель Windows прекрасно ложится на любую оконную систему

Это попросту не так.

реализована везде, кроме Wayland

Везде, где была цель создать традиционную оконную систему. Wayland вообще не занимается логикой размещения окон и подобным. Нет принципиальной невозможности воссоздать Windows-like DE в Wayland, но это не так много кому нужно. Кому нужно, пилят kwin+plasma/mutter.

Эта модель ломается уже при добавлении воркспейсов

Поясните как?

Приложениями должна управлять операционная система (под управлением пользователя)

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

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

Проблема приложения или юзера.

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

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

Wayland вообще не занимается логикой размещения окон и подобным.

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

Эта модель ломается уже при добавлении воркспейсов

УМВР. Проверено на Haiku, KDE и Windows 10.

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

Операционная система не может знать всех тонкостей размещения окон. Посмотрите например как в Mac OS работает размещение окон меню, это в принципе не сделать без абсолютного позиционирования и знания размера экрана. Что-то близкое в Haiku, более простое (но всё равно не совместимое с Wayland) в Windows и Qt.

Я говорю про принципиальную модель взаимодействия юзер-система-приложения.

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

В новости по ссылке пишут

It does mean, however, that GTK 2 has reached the end of its life. We will do one final 2.x release in the coming days, and we encourage everybody to port their GTK 2 applications to GTK 3 or 4.

То есть ещё одно обновление планируют выпустить.

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

Как из порталов логически вытекает телеметрия, привязка к телефону и др.? Я не вижу связи. Я имею в виду https://github.com/flatpak/xdg-desktop-portal, если что.

Проблема приложения или юзера.

А почему юзер должен бороться с приложениями, исправить поведение которых нет возможности? Пользователь хочет,

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

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

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

Верно, и приложение просит у ОС что-то сделать, так как у самого приложения есть информация о своем внутреннем состоянии.

Ну а юзера всё время дёргать,

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

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

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

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

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

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

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

передачу сообщений между приложениями

Wayland это не не умеет, для этого есть D-Bus.

б) не мешало пользоваться другими приложениями

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

УМВР. Проверено на Haiku, KDE и Windows 10.

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

Без логики управления окнами нечего склеивать.

Вы серьезно думаете, что вы что-то умное написали?

Wayland это не не умеет, для этого есть D-Bus.

Поправлю, между приложениями и композитором.

Какие абсолютные координаты у окон на двух разных воркспейсах?

Одинаковые. Программам про рабочие пространства знать не обязательно, достаточно создавать новые окна в текущем рабочем пространстве. При необходимости есть API для задания рабочего пространства окну, но мало кто им пользуется. Рабочими пространствами обычно управляют с помощью WM.

Поправлю, между приложениями и композитором.

Wayland тут зачем? Его можно вообще чисто на D-Bus заменить.

flatpak

https://flatkill.org/

а) чтобы приложение работало так, как ему нужно

Только в случае наличия у него достаточной компетенции чтобы он понимал что ему нужно (т.е. если пользователь гик)

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

Этот пользователь не гик, у него недостаточно компетенции, чтобы быть ЛПР, хотя и очень хочется.

И даже если да, будет ли у него желание вообще пользоваться таким приложением, в которое нужно вносить какие-то правки для нормальной работы?

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

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

Вам в Dota2 надо пойти играть и чтобы в замесе ОС у вас вежливо спросила, «не желаете ли вы обновлений, сударь?» Или вообще ещё лучше «обновления приехали, а давайте перезагрузимся». Тогда поймёте о чём я говорю.

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

А юзеру охота думать над каждым разрешением? Он просто будет давать все и всё. Как с лицензиями на ПО, которые никто не читает. Это кстати известный факт, ради исследования челики включили туда пункт про то что им надо отдать первенца, а в случае неточностей в лицензии обратиться по такому-то адресу и на это жаловалось меньше 1% пользователей.

https://wayland.freedesktop.org/faq.html#heading_toc_j_10

I wanted to preserve some important properties from the X protocol: the ability to queue up an event or request by just memcpy’ing into the protocol out-buffer. That’s what wl_connection_write does. Furthermore, it lets us memcpy several messages into the buffer and only write it all before we go back to blocking in the main loop. Second, everything is explicitly asynchronous, which is a really powerful feature in a protocol.

I wanted to preserve some important properties from the X protocol

Лучше бы D-Bus доработали, а не создавали новые протоколы. Да и подобный механизм можно сделать и не в Wayland. Тащить ущербность его основных протоколов ради асинхронности - не логично.

А что касается безопасности от вялых и прочих firejail-ов, это вредоносные приложения, которые создают у пользователя иллюзию безопасности и вместо того чтобы расчехлить серёзные инструменты и запариться обеспечением реальной безопасности, юзер верит всему этому фарсу и театру безопасности, становясь жертвой злоумышленников. ИМХО на законодательном уровне авторы таких решений должны нести ответственность за базар, т.е. в случае взлома из-за ошибок в их говноподелиях считаться полноценными соучастниками. Ну или пусть крупными буквами пишут, что ПРИЛОЖЕНИЕ НЕ ОБЕСПЕЧИВАЕТ БЕЗОПАСНОСТЬ, МЫ ОТКАЗЫВАЕМСЯ ОТ ЛЮБЫХ ОБЯЗАТЕЛЬСТВ ПЕРЕД ПОЛЬЗОВАТЕЛЯМИ НАШЕГО ПРОДУКТА. И эта надпись должна быть самым большим шрифтом на экране юзера при установке данного ПО.

Ну или пусть крупными буквами пишут, что ПРИЛОЖЕНИЕ НЕ ОБЕСПЕЧИВАЕТ БЕЗОПАСНОСТЬ, МЫ ОТКАЗЫВАЕМСЯ ОТ ЛЮБЫХ ОБЯЗАТЕЛЬСТВ ПЕРЕД ПОЛЬЗОВАТЕЛЯМИ НАШЕГО ПРОДУКТА.

Это и так почти во всех свободных лицензиях написано.

Это есть в тексте лицензии.

https://flatkill.org/

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

чтобы он понимал что ему нужно (т.е. если пользователь гик)

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

у него недостаточно компетенции, чтобы быть ЛПР, хотя и очень хочется.

Вот именно. А нажать кнопку «Нет, запретить» никакая компетенция не нужна.

ОС у вас вежливо спросила, «не желаете ли вы обновлений, сударь?» Или вообще ещё лучше «обновления приехали, а давайте перезагрузимся».

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

и чтобы в замесе ОС у вас вежливо спросила,

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

А юзеру охота думать над каждым разрешением? Он просто будет давать все и всё.

Пусть дает, его проблемы. Кому надо, тот не будет давать.

Как с лицензиями на ПО, которые никто не читает.

Лицензии на ПО содержат тысячи строк текста. Запрос на фуллскрин – одну-две.

Вот только их никто не читает. А надо чтобы при установке эта надпись имела кнопку ОК и при её нажатии не пропадала сразу, а висела ещё 15 секунд.

А что касается безопасности от вялых и прочих firejail-ов, это вредоносные приложения,

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

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

Очень смущает.

Пусть дает, его проблемы. Кому надо, тот не будет давать.

Нет, эту проблему надо решать, а не перекладывать на юзера.

не удивлюсь что можно получить доступ к памяти Wayland сервера из клиента.

Ну так получи и приходи тогда.

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

Переключить на другое рабочее пространство и проблема решена.

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

Т.е. у него стабильное api, на нём можно сделать полноценный тайлинг, со скриншотами, скринкастами и глобальными хоткеями, а так же предоставляет инструменты для удалённого проброса окна приложения на другую машину? И это всё будет гарантированно работать на всех более-менее адекватных конфигурациях? Бегу писать WM для него, постойте, а где там документация? Завезут через 20 лет? Или надо на почту разрабам вялого писать? Точек отказа меньше, чем у иксов?

Бегу писать WM для него

Много WM-ов под иксы уже написал, пейсатель ты наш?

А под иксы сейчас нет смысла писать (вообще ничего), оно умрёт не смотря на то что мне не нравится вялый, потому что красношапка если не обанкротится его всё равно продавит.

Ну и Openbox как бы уже написан.

Т.е. у него стабильное api

Да.

на нём можно сделать полноценный тайлинг

Да.

со скриншотами

Да.

скринкастами

Через pipewire – да.

глобальными хоткеями

Да, но с оговорками. Глобальные хоткеи, которые приложения «назначают» сами себе – нет, т.е. отваливается глобальный push-to-talk. Остальные просто задаются через композитор и нормально работают.

а так же предоставляет инструменты для удалённого проброса окна приложения на другую машину?

См. waypipe. Пока сыро, но более-менее работает.

а где там документация?

API и краткое описание лежит на freedesktop.

Точек отказа меньше, чем у иксов?

Точек отказа чего?

Бегу писать WM для него

Не выйдет. Там нет разделения на GUI-сервер и оконный менеджер как в X11, вместо этого один монолитный процесс. Протокол сделали расширяемым, зато сам сервер стал монолитным.

Точек отказа чего?

Ну вот я по ответам увидел что больше.

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

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

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

При удачном раскладе претендует на полное закапывание десктопного Линукса вместе с ядром и тулкитами.

Вслух проиграл😂 Дед опять таблетки забыл принять😏

Для нетайловых WM модель Windows прекрасно ложится на любую оконную систему и реализована везде, кроме Wayland.

Если Шиндвс так хороша, что ты делаешь здесь? Шиндвс уже есть, зачем нам нужна ещё одна?

Вредители.

А под иксы сейчас нет смысла писать

расшифровываю: я не могу ничего написать ни под иксы, ни под Wayland, но свое авторитетное мнение по этому поводу имею.

Я не программист и не админ. У меня проблем нет. Мне линукс нужен.

Твой профиль, что ты тут забыл то?

Там нет разделения на GUI-сервер и оконный менеджер как в X11, вместо этого один монолитный процесс.

Это, мягко говоря, не так. Там нет принудительного разделения на GUI-сервер и оконный менеджер, но нет и препятствий разделять. Разделять или нет – это отдается на откуп реализующему композитор.

broadway-backend

- ого, я думал его выпилили.

это отдается на откуп реализующему композитор.

Что никто из реализующих композитор не делает.
И, ЧСХ, реализовать композитор в разы сложнее и более трудоёмко, чем напимать window менеджер.

Разделять или нет – это отдается на откуп реализующему композитор.

И все существующие реализации монолитные… Если в протоколе нет стандартных интерфейсов взаимодействия между GUI-сервером, композитором, WM и DE (панель задач и т.п.), то даже если они будут разными процессами, вместе с другими реализациями они работать не будут. В X11 есть стандартные протоколы для WM и DE и можно составлять разные рабочие комбинации.

Согласен.

А значит, чтобы сделать хорошо, надо повторить большУю часть X11, но уже в композиторе.

В итоге получается софистика: wayland прогрессивен, лёгок и прекрасен потому, что всё остальное теперь пихаем в композитор, а не потому, что остальное не нужно.

повторить большУю часть X11, но уже в композиторе

wayland прогрессивен, лёгок и прекрасен потому, что всё остальное теперь пихаем в композитор,

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

всё остальное теперь пихаем в композитор

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

Нет, потому что не нужно нигде повторять остальную часть

Нужно. Логику управления окнами и вводом никто не отменял.

композитора

Не надо называть GUI-сервер «композитором». Композитор - это программа для рисования буферов на экран и не более того. В Windows (dwm.exe), Android (SurfaceFlinger) композитор и GUI-сервер - это отдельные процессы.

Я в курсе. Согласен, моя ошибка – применил термин по привычке, так как, опять же, в Wayland обычно это одное целое.

Твой профиль, что ты тут забыл то?

А что, нельзя? Ну и я же ни пишу никаких WMов ни под иксы, ни под Wayland, и даже не рассуждаю о том, что из этого проще.