Разработчики GNOME объявили о планах отказаться от поддержки X11

Это проблема UX. Как пользователю, мне исключительно плевать, чья.

Прикол в том что в иксы уже давно не добавляют никаких фич. А вот в wayland - да.

Да.

Когда каждый вася вынужден лепить свой «протокол» для захвата экрана, это не костыли? И как же это назвать? Архитектура с большой буквы А?

Никто ничего не лепит. Есть PipeWire, есть порталы. С недавних пор заапстримили wlr-screencopy. И да - это не костыли

А pipewire есть на bsd? Или там все развалится?

На FreeBSD есть, на остальных не знаю.

wlr-screencopy

А что такое wlr? Не лепит, ага.

Сделали в wlroots, обкатали у себя, предложили в апстрим, сообща допилили до ума. В чем проблема? Большая часть wayland-protocols так и была заапстримлена. Минус тут только один - все медленно очень было.

В чем проблема?

В том, что пока несли, стандартом стали порталы, которые вообще сбоку и пилятся авторами флатпака, один из которых страдает что у них кончились мейнтейнеры и новые фичи никто не несет %)

один из которых страдает что у них кончились мейнтейнеры и новые фичи никто не несет

Это кто там такой страдалец?

В том, что пока несли, стандартом стали порталы

Минусы будут?

https://lwn.net/Articles/1020571/

The reason for the lack of reviewers is that key people, such as Larsson, have left the project. Every now and then, Wick said, Larsson may get involved if it’s necessary, but he is basically not part of the day-to-day development of the project. Wick said that it is hard to get new Flatpak contributors involved because it can take months to get feedback on major changes, and then more months to get another review. «This is really not a great way to get someone up to speed, and it’s not a great situation to be in.»

«Maybe I’m complaining about something that is actually not that much of an issue», he said. Flatpak works; it does its job, and «we just use it and don’t think about it much». In that sense, the project is in a good spot. But he has still been thinking about how the project is «living with constraints» because contributors do not have the opportunity to go in and make bigger changes.

As an example, Wick said that Red Hat has been doing work that would allow Flatpaks to be installed as part of a base installation. The vendor or administrator could specify the applications to be installed, and a program called flatpak-preinstall would take care of the rest. The feature has been implemented and is planned for inclusion in Red Hat Enterprise Linux (RHEL) 10. The work was started by Kalev Lember and Owen Taylor last June, but the original pull request was closed by Lember in February as he was leaving Red Hat and would not be working on it anymore. It was picked up by Wick in February as a new request but wasn’t reviewed until early May.

Минусы будут?

Архитектурно? Сбоку вырос еще один стек, который для решения задачи совершенно не нужен и дублирует ext-screencopy или как его назвали.

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

для решения задачи совершенно не нужен

Нужен, ибо задачу эту успешно решает не только для Wayland, но и для sandbox окружений.

дублирует ext-screencopy

Он тоже может работать через порталы, поскольку портал обращается через D-Bus к интерфейсу композитора, который передает ему файловый дескриптор, и соответсвенно гоняет видеопоток на PipeWire. Сейчас это сделано приватными интерфейсами внутри композитора, в кедах это org.kde.Screenshot2 например. ext-image-copy просто заменит этот интерфейс на общий для всех. Сейчас например скриншотилка Spectacle работает именно с org.kde.Screenshot2, прикрутят ext-image-copy - будет работать с ним. Но порталы никуда не денутся, одно не заменяет другое, понимаешь? Никто же после мержинга этого протокола в композиторы не выкинет к херам порталы.

К слову, xdg-desktop-portal-wlr например так и работает - для скриншота вызывается grim, который поддерживает wlr-screencopy, и с недавних пор новые протоколы.

Нужен, ибо задачу эту успешно решает не только для Wayland, но и для sandbox окружений.

У sandbox окружений нет Wayland сокета? Как они тогда окно рисуют?

Он тоже может работать через порталы, поскольку портал обращается через D-Bus к интерфейсу композитора, который передает ему файловый дескриптор, и соответсвенно гоняет видеопоток на PipeWire.

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

• композитор
• xdg-desktop-portal
• xdg-desktop-portal-impl
• dbus
• pipewire
• скриншотилка

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

Сейчас это сделано приватными интерфейсами внутри композитора, в кедах это org.kde.Screenshot2 например. ext-image-copy просто заменит этот интерфейс на общий для всех. Сейчас например скриншотилка Spectacle работает именно с org.kde.Screenshot2, прикрутят ext-image-copy - будет работать с ним. Но порталы никуда не денутся, одно не заменяет другое, понимаешь? Никто же после мержинга этого протокола в композиторы не выкинет к херам порталы.

Опять же, плюсы-то где? Теперь нужно поддерживать в два раза больше кода.

У sandbox окружений нет Wayland сокета?

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

Плюсы-то где?

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

Опять же, плюсы-то где? Теперь нужно поддерживать в два раза больше кода.

Ты так говоришь, будто поддерживать предстоит тебе. Ответ прост - добавляются протоколы, которые приняты в апстрим, какое-то время, пока большинство клиентов не получат их поддержку, поддерживается старый интерфейс. А потом - выпиливается. И все. Там по сути никакой поддержки и не требуется, этот код никто не трогает. Как например делали с wl-shell и xdg-shell-unstable-v6.

Понятно, доказательств у вас нет, одна лишь голословность.

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

Да как бы нет. Есть grim, он прекрасно работает через протокол и копирует экран. Для доступа к отдельным окнам наконец-то принесли вот эти два:

• https://wayland.app/protocols/ext-image-capture-source-v1
• https://wayland.app/protocols/ext-image-copy-capture-v1

И XDPW будет работать как раз через них. Порталы для решения этой задачи не нужны.

Для проверки разрешений появился этот протокол:

• https://wayland.app/protocols/security-context-v1

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

А есть вариант лучше?

Есть, воспользоваться теми протоколами, что наконец-то появились. Просто появились они поздно.

Какая разница как оно реализовано, если оно работает?

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

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

Смотри протоколы выше.

Для людей это нормально – не уметь читать и бредить. Более того, из живых, только люди могут бредить

Порталы для решения этой задачи не нужны.

Для Flatpak они будут нужны всегда. Для остального - да, можно будет обойтись без непосредственно портала. Но. Ты правильно сделал, что упомянул security-context. Только вот он немного для другого нужен, и работу портала никак не исключает. А наоборот - дополняет.

И XDPW будет работать как раз через них

Он сейчас и так работает через wlr-screencopy, но посредством grim. Выше написал.

Но я же начал разговор про разработчика.

Почему ты говоришь за какого-то гипотетического разработчика? Тебе самому приходилось реализовывать поддержку того или иного Wayland протокола в приложухе? Мне - да.

Смотри протоколы выше.

Как наличие этих протоколов противоречит моим словам, что

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

? Ты буквально повторяешь мои слова. Естественно юзать портал для штатной скриншотилки например - тупо. Spectacle так не делает. По-моему это и так очевидно.

Для Flatpak они будут нужны всегда. Для остального - да, можно будет обойтись без непосредственно портала. Но. Ты правильно сделал, что упомянул security-context. Только вот он немного для другого нужен, и работу портала никак не исключает. А наоборот - дополняет.

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

Он сейчас и так работает через wlr-screencopy, но посредством grim. Выше написал.

screenshotter -> dbus -> XDPW -> grim -> wlr-screencopy -> wlroots

вместо

screenshotter -> wlr-screencopy -> wlroots

Выглядит как наркомания и ad-hoc solution, вот честно.

Почему ты говоришь за какого-то гипотетического разработчика? Тебе самому приходилось реализовывать поддержку того или иного Wayland протокола в приложухе? Мне - да.

Мне тоже. Потом выяснилось, что этого протокола ещё не существует и мне предложили идти его делать в wayland-protocols. Сказали что займет год-полтора со всеми итерациями. Я сказал «ха-ха» и поставил KDE.

Как наличие этих протоколов противоречит моим словам, что в Wayland невозможно просто так получить содержимое окна:

Потому и требуется во первых реализация специального интерфейса в композиторе

Потому что ты опять привел не всю цитату:

Потому и требуется во первых реализация специального интерфейса в композиторе, во-вторых - портала, в третьих - их общение через D-Bus.

Пункты 2-3 не требуются :)))

Естественно юзать портал для штатной скриншотилки например - тупо. Spectacle так не делает. По-моему это и так очевидно.

Штатная скриншотилка – вот моя претензия. Нет общей скриншотилки, которая бы работала через Wayland без pipewire. Надо для каждого композитора свою писать, а потом сверху обмазывать dbus чтобы написать ещё одну скриншотилку, которая будет вызывать эту скриншотилку. Ну это же дичь.

Выглядит как наркомания и ad-hoc solution, вот честно.

Не будет он напрямую с wlroots по твоей схеме работать. Эти протоколы - не какая-то волшебная пилюля. Это просто стандартизация тех самых кастомных D-Bus интерфейсов, что сейчас есть в Kwin, Mutter и wlroots. Вот и все. Никто от порталов не будет отказываться. Что касается security-context - он нужен для композитора, но не для клиента. Чтобы следить за полномочиями песочниц, и ограничивать им доступ к привелегированным интерфейсам. Он не замена порталу, они разные задачи выполняют. Поэтому никакого волшебства не случится. Разве что однажды, Spectacle сможет работать в wlroots (я сомневаюсь что GNOME эти протоколы примет).

Потом выяснилось, что этого протокола ещё не существует и мне предложили идти его делать в wayland-protocols

Интересно, что это было, что аж целый протокол пилить тебя отправили?

Не будет он напрямую с wlroots по твоей схеме работать. Эти протоколы - не какая-то волшебная пилюля.

Уже год работает: https://gitlab.freedesktop.org/emersion/grim/-/commit/dee622a73144672d874f7a906c55711f68bbd198

Чтобы копирование из окна добавить, осталось принести туда второй протокол.

Это просто стандартизация тех самых кастомных D-Bus интерфейсов, что сейчас есть в Kwin, Mutter и wlroots.

В wlroots их сейчас вообще нет. В wlroots нельзя отдельное окно выделить, это просто невозможно, для этого нет методов. Эти протоколы их как раз и приносят.

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

Я этого и не утверждаю.

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

Буквально одно и то же, лол. Просто одно через нативные интерфейсы Wayland, второе через dbus API. А так разницы нет буквально никакой: что один позволяет тебе возможность проверить кто к тебе пришел, что второй.

Интересно, что это было, что аж целый протокол пилить тебя отправили?

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

А вас видимо задевает что кто-то там обижает компанию с многомиллионными оборотами.

Уже год работает

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

В wlroots их сейчас вообще нет. В wlroots нельзя отдельное окно выделить, это просто невозможно, для этого нет методов. Эти протоколы их как раз и приносят.

Ну да, ядрен батон я же это и говорю - сюда приносит, в других стандартизирует. Будто на разных языках общаемся.

Я этого и не утверждаю.

И XDPW будет работать как раз через них. Порталы для решения этой задачи не нужны.

Смотри протоколы выше.

А это что? По-моему ты не совсем понимаешь, что такое xdg-desktop-portal в принципе, раз для тебя он и security-context - одно и то же. Так и быть, последний раз объясню. xdg-desktop-portal - это механизм доступа приложения к определенным интерфейсам композитора, например шинам D-Bus, шине уведомлений, захвату экрана таки (и то после того как юзер добро даст на это) и так далее. security-context - это механизм композитора, который узнает, что приложение запущено в песочнице и на свое усмотрение - может реализовать для неё ряд ограничений. Для песочницы, не для приложения. А именно - запрет на создание вложенных песочниц, запрет доступа к привелегированным интерфейсам композитора (опять таки к захвату экрана, если никак нельзя к нему доступ получать) и так далее. Все, что делает security-context - это передает композитору app_id приложения, движок песочницы и ID экземпляра запущенного приложения. Чтобы уже на основании этой информации создавать политику доступа. Считай это сильно упрощенным аналогом SElinux. Вот и все.

Дай угадаю - абсолютное позиционирование окон?))

Ресайз то хоть разрешает барин?

Ты пользуешься убогим плеером.

Ну да, ядрен батон я же это и говорю - сюда приносит, в других стандартизирует. Будто на разных языках общаемся.

Если приносится универсальный протокол, теряется смысл в dbus API.

Так и быть, последний раз объясню. xdg-desktop-portal - это механизм доступа приложения к определенным интерфейсам композитора, например шинам D-Bus, шине уведомлений, захвату экрана таки (и то после того как юзер добро даст на это) и так далее. security-context - это механизм композитора, который узнает, что приложение запущено в песочнице и на свое усмотрение - может реализовать для неё ряд ограничений. Для песочницы, не для приложения.

В security-context прописаны sandbox engine, app id и instance id. Это буквально идентифицирует приложение внутри sandbox. Ты протокол-то читал? :)

«отлично» это когда у меня нет возможности тролить тебя предложением захватить скринкаст черзе ffmpeg напрямую. Он отлично умеет Х11, винду, макось и вероятно что то ещё. Но не может научиться вайланд потому что в вайланде хрень и бардак вместо api видеозахвата.

В security-context прописаны sandbox engine, app id и instance id. Это буквально идентифицирует приложение внутри sandbox. Ты протокол-то читал? :)

Да. И в отличие от тебя я понял как он работает и для чего нужен.

А pipewire есть на bsd?

А оно ещё не сдохло?

В чем проблема?

стандартом стали порталы, которые вообще сбоку и пилятся авторами флатпака

А проблема-то в чём?

А проблема-то в чём?

Архитектурно? Тестирование, коммуникация, баги, потенциальная смерть мейнтейнеров flatpak. Юзеру насрать, пока все работает, тут ты прав.

Ну, наверное, стоит смотреть на модели несколько дороже 50 000 рублей…

Ты долбанулся? Это просто монитор, он не может столько стоить. Может мне ещё сходить, посмотреть на хлеб по цене 5000р за булку? Если бы у меня были комплексы на тему денег - для меня была бы очевидно превосходство такого хлеба над любым другим даже если бы он был сделан из плохо запечёного навоза.

там тоже oled с hdr
oled

В топку это говно!

Он делается для компаний.

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

И никаких настроек.

И зачем было придумывать гном и вайланд? Голый Х11 - идеальный вариант. Ещё отлично подойдёт twm и i3, но это уже для сеньоров и руководителей отделов.

Да. И в отличие от тебя я понял как он работает и для чего нужен.

Смари: https://wiki.hyprland.org/Configuring/Permissions/

Ровно то же самое теперь прекрасно запиливается с security-context. Просто вместо пути к приложению ты пишешь пару sandbox_engine + app_id.

Да не то же самое там, лол)) ля как с тобой трудно однако

Да не то же самое там, лол)) ля как с тобой трудно однако

Объясни же разницу между /usr/bin/grim screencopy, allow и flatpak,grim screencopy, allow.

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

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

Ещё и в пример Hyprland привел, лол, где вообще своя Wayland реальность. security-context - не замена, а дополнение к порталам. И я выше написал как оно работает. Оно физически не может заменить портал. По твоей же ссылке:

xdg-desktop-portal implementations (including xdph) are just regular applications. They will go through permissions too.

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

Ты не ответил на вопрос. Чем отличается /usr/bin/grim screencopy, allow и flatpak,grim screencopy, allow? Поддержка security-context позволяет реализовать второй вариант.

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

Ты реально думаешь что это и есть троллить? Иди соевого молока хлебни, мальчик :-D :-D :-D

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

Соя усвояется чуть ли не лучше остального белка, никогда не понимал этого странного тейка.

Тестирование, коммуникация, баги

А что, есть какая-то альтернатива где всё это внезапно не проблема?

потенциальная смерть мейнтейнеров flatpak

Что это за магическое мышление такое? Ты полагаешь что со смертью человека написанный им код превращается в тыкву?

Поддержка security-context позволяет реализовать второй вариант.

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