Window in window = compositor in compositor

Потому что композитор в том виде, как он в wayland - это рак.

какие задачи это должно решить?

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

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

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

Имеем что имеем.

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

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

но, думаю, это вопрос времени

Точнее, надеюсь.

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

wayland с клиентской стороны - это фреймбуфер, композитор - это кривой X-server почти без функциональности. На DE вообще не тянет.

Мне кажется идея интересная. А есть какой то прототип?

почему идея дерьмо или же не дерьмо

Потому, что это уже опробовали. Если не ошибаюсь такое было еще в dos, потом решили, что практичней рутовое окно без рамок и на весь экран.

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

Если такое реализовывать на wlroots - могут появиться проблемы. Если запускать вложенную wayland-сессию, во всяких гномах не появляются декорации. Добавлять поддержку libdecor они почему-то не хотят. То есть надо патчить. В иксах и нормальных DE всё работает. А вот как в таких ситуациях ведёт себя Mir - честно, пока не проверял. Mir использовать в принципе боюсь. Оно удобное, красивое, на плюсах и современное - но по репозиторию мне кажется, что разработка стагнирует.

Сама по себе идея использовать вложенный композитинг для реализации окон в окне у меня побочная. Сейчас в свободное время пытаюсь писать для себя одну маленькую GUI-утилитку… И исследую вопрос, как это можно оптимально сделать.

Требования несколько специфичные. Мне нужно, чтобы она могла по требованию (например, посредством запуска юнита systemd) запускаться в любом указанном незанятом TTY. Поэтому нужен композитор. Для такого обычно применяют киоски вроде Cage, но мне нужна ещё некоторая интеграция и заточенность киоска на именно мой программулину:

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

Потом уже понял, что благодаря вложенным Wayland-сессиям при лёгком допиле я смогу ту же самую утилиту запускать не только в TTY, но и на основном рабочем столе наряду с отдельными приложениями. Что иногда удобно.

Там уже и докатился до идеи, что личный композитор, специфичный для приложения - это клёвая тема и может дать значительные бонусы для разработки. В некоторых очень узких, но существующих сценариях. Как минимум, вижу возможность запускаться из TTY без запуска внешнего DE/WM, удобные нативные окна в окне и реализация всякой специфичной для приложения херни и протоколов.

Благодаря тому, что wayland для приложения - это всего-лишь буффер, получаем околонулевой импакт на производительность. А благодаря лёгкости и модульности протокола и его реализаций, выходит, что это почти не добавляет приложению в весе. Тот же киоск cage весит 2 мегабайта. Что вполне простительно для любого гуёвого приложения и тем более простительно, если к нему настолько необычные требования.

Это уже холливар какой-то. Тема же не об этом. Ваши претензии к wayland полностью понимаю. Пустота Wayland с лихвой компенсируется расширениями протокола. Думаю, мы в любом случае придём к их стандартному набору, которые должен реализовывать любой уважающий себя композитор. Малину портит только то, что все тянут одеяло на себя. Как тот же гном, отчаянно отказывающийся от CSD. Просто надеюсь, что эти проблемы временные. А для моих скромных сценариев всё работает уже достаточно хорошо.

Расскажете немного подробнее? Или хотя бы по каким кейвордам искать. Меня в том палеозое ещё на свете не было, так что с работой DOSов не знаком практически никак.

Я уже не помню, что-то похожее на Norton Desktop.

Вот так понятнее. Кстати, X11 без композитинга и сглаживания шрифтов ещё легче.

В иксах есть Xephyr и он полностью изолирует приложение, но не знаю где это юзают.

захват ввода - посмотри на протокол drm-lease, возможно там что-то похожее.

IPC опять же можно реализовать в виде кастомного Wayland протокола

в общем цель наверно достижимая, но придётся кодить.

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

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

За наводку по drm-lease спасибо! При запуске киоска в отдельном терминале оно не появится, но если появится нужда околобесшовно его запускать как приложение — вполне пригодится.

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

А кодить придётся. Таков путь…

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