LINUX.ORG.RU

Window in window = compositor in compositor

 , , ,


0

1

Недавно пришла такая идея.

Суть: мы ведь можем запускать Wayland-сессии внутри материнских Wayland-сессий вложенно.

Тогда почему бы для рендеринга типа окно-в-окне (аналогично как в гимпе) не использовать дочерние Wayland-композиторы?

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

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

Получается некий libnested, наподобие libdecor.

Идея простая как палка. Собрать свой Wayland-композитор нынче может любая макака. Хочешь используй wlroots, хочешь используй Mir.

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

А теперь, пожалуйста, объясните мне, почему идея дерьмо или же не дерьмо. Возможно, есть подводные и я их в упор не вижу.



Последнее исправление: witaway (всего исправлений: 1)

Ответ на: комментарий от anonymous

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

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

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

witaway
() автор топика
Ответ на: комментарий от Shadow

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

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

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

witaway
() автор топика

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

witaway
() автор топика
Ответ на: комментарий от imatveev13

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

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

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

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

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

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

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

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

witaway
() автор топика
Ответ на: комментарий от Shadow

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

witaway
() автор топика
Ответ на: комментарий от dmitry237

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

witaway
() автор топика
Ответ на: комментарий от witaway

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

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

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

Lrrr ★★★★★
()
Ответ на: комментарий от Shadow

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

witaway
() автор топика
Ответ на: комментарий от Lrrr

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

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

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

witaway
() автор топика