LINUX.ORG.RU

Принудительное использование X11 в Qt-приложениях из flatpak

 , ,


0

0

Здравствуйте!

В связи с проблемами с X-сервером временно переполз на Wayland и тут же столкнулся с отвратительной его поддержкой установленными у меня приложениями на Qt: проблемы с копированием-вставкой, отсутствие теней и границ у окон, отчего всё сливается в кашу…

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

QT_QPA_PLATFORM=xcb

Однако возникла проблема с Qt-приложениями, установленными с помощью flatpak:

aleksej@lenovo:~$ export QT_QPA_PLATFORM=xcb
aleksej@lenovo:~$ flatpak run org.flatpak.qtdemo 
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

aleksej@lenovo:~$ 

Т.е. сам плагин есть, но почему-то не может достучаться до X-сервера. Xwayland при этом запущен и работает. Переменная DISPLAY есть и имеет правильное значение; принудительная передача её через --env=… ничего не меняет.

Передача опции --socket=x11 также ничего не даёт.

Приложения вне flatpak работают через Xwayland без проблем.

Те же Qt-приложения в flatpak также работают без проблем в X-сессии.

Единственный выход, который я пока нашёл, — это отключение доступа у соответствующих приложений к wayland-сокету целиком: flatpak run --nosocket=wayland org.flatpak.qtdemo — тогда приложения магическим образом начинают работать, как требуется. (Почему простого указания платформы им недостаточно, и требуется аж запрещать доступ к Wayland, чтобы они наконец начали использовать X11?) Однако это плохо масштабируется: нужно делать это для каждой установленной программы.

Кто-нибудь сталкивался с подобной проблемой? Может, у кого-то есть мысли, как её можно решить лучше?

  • Debian 11
  • GNOME 3.38
  • flatpak 1.10.2
  • версия Qt в runtime — 5.15
★★★★

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

А в чём проблема то? flatpak override и в путь. А ещё можно flatseal поставить.

отвратительной его поддержкой установленными у меня приложениями на Qt: проблемы с копированием-вставкой, отсутствие теней и границ у окон, отчего всё сливается в кашу…

Ну что тут сказать? Ещё одна причина отказаться от приложений на Qt. Даже во флатпаке, где по большей части на тулкит побоку.

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

А в чём проблема то? flatpak override и в путь.

Да оно понятно, просто лениво каждый раз при установке очередного приложения это делать. Выставление переменной окружения — это было бы решение «раз и навсегда», но почему-то не работает.

Вообще говоря, это похоже на баг. Если смогу разобраться, где именно: в Qt-ли, в mutter-ли, или же в самом flatpak — оформлю отчёт об ошибке.

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

Можно сделать глобальный override, но тогда наоборот, придётся разрешать доступ к вейланду тем приложениям, которые работают на нём нормально. А ты так часто ставишь новые приложения?

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

Вообще говоря, это похоже на баг. Если смогу разобраться, где именно: в Qt-ли, в mutter-ли, или же в самом flatpak

Конечно в Qt. Почему в нем такая дерьмовая поддержка wayland?

eternal_sorrow ★★★★★ ()

полагаю потому что флэтпак внутри себя переопределяет что-то вроде QT_QPA_PLATFORM= «wayland; xcb»

с приоритетом на вэйланд если доступен так как ЕМНИП в будущем от поддержки иксов во флэтпаке планируется избавиться полностью.

кстати вот такой вариант вроде работает в отличие от экспорта [code]QT_QPA_PLATFORM=xcb flatpak run[/code]

Thero ★★★★★ ()
Последнее исправление: Thero (всего исправлений: 1)
Ответ на: комментарий от Thero

кстати вот такой вариант вроде работает в отличие от экспорта [code]QT_QPA_PLATFORM=xcb flatpak run[/code]

Между export FOO=bar; command и FOO=bar command нет абсолютно никакой разницы, это эквивалентные конструкции в Bourne shell (и POSIX sh).

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Thero

полагаю потому что флэтпак внутри себя переопределяет что-то вроде QT_QPA_PLATFORM= «wayland; xcb»

Если бы это было так, то выставление переменной окружения не имело бы ровным счётом никакого эффекта. Однако же, это не так: Qt пытается использовать указанную платформу, но не может.

QT_QPA_PLATFORM=xcb flatpak run

Это эквивалентная конструкция, но если так у вас работает, то назовите свой дистрибутив - проверю, в чём разница.

Rootlexx ★★★★ ()

это отключение доступа у соответствующих приложений к wayland-сокету целиком

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

проблемы с копированием-вставкой, отсутствие теней и границ у окон, отчего всё сливается в кашу…

Скажи спасибо гномовцам, которые не хотят добавлять серверные декорации в Mutter. Плагин QGnomePlatform особо не спасает. В KDE и Sway всё работает как положено.

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

Скажи спасибо гномовцам, которые не хотят добавлять серверные декорации в Mutter

Справедливости ради, протокол xdg-decoration является опциональным, поэтому все приложения, работающие в Wayland, обязаны поддерживать CSD, и если они это нормально не делают, это никак нельзя оправдать существованием xdg-decoration.

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

хм странно просто в некоторых репортах на некоторых куте программах один вариант работает а другой нет.. но возмоно репорты неточны.

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

Справедливости ради, протокол xdg-decoration является опциональным, поэтому все приложения, работающие в Wayland, обязаны поддерживать CSD, и если они это нормально не делают, это никак нельзя оправдать существованием xdg-decoration.

Так а с каких пор разработчики Qt должны отслеживать изменения в дизайне GNOME и думать про тени и CSD там? Поддержка Qt приложений в GNOME полностью легла на плечи GNOME-разработчиков, раз они не захотели стандартизировать xdg-decoration или просто предоставить какую-нибудь libdecoration со стабильным API реализующую CSD по HIG’у и текущим мокапам. Сторонние проекты не должны следить за изменениями UX/UI и дизайна DE.

В итоге всё что получилось у GNOME-разработчиков – это сделать корявую интеграцию – https://github.com/FedoraQt/QGnomePlatform, которая толком не работает и кривая.

EXL ★★★★★ ()

Известная проблема org.kde.Platform. Кроме отключения wayland сокета, есть еще один вариант: откатитесь к коммиту f8cad41da8048b4001dfade78b4c234e6b3bccfd7db714310dbaae0b31077561 – УМВР с wayland, а после него все сломали.

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

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

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

Так а с каких пор разработчики Qt должны отслеживать изменения в дизайне GNOME и думать про тени и CSD там?

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

просто предоставить какую-нибудь libdecoration со стабильным API реализующую CSD по HIG’у и текущим мокапам

Типа этого?

Сторонние проекты не должны следить за изменениями UX/UI и дизайна DE.

Вспоминаю, как Opera много лет назад, когда ещё ни о каком Wayland всерьёз не заикались, рисовала свой интерфейс, мимикрируя под основную тему KDE с его радиальным градиентом, переходящим из фона окна в заголовок; а потом тему в последнем поменяли, и мимикрия в Opera сломалась.

И да: почему-то проекты вроде Google Chrome могут подстраивать свой внешний вид под окружение, а Qt не может?

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

А вот это уже интересно. Похоже, проблема в этом патче.

Вроде как об этой проблеме неделю назад уже сообщили разработчикам, т.ч. посмотрим.

Спасибо!

Rootlexx ★★★★ ()
Последнее исправление: Rootlexx (всего исправлений: 1)
Ответ на: комментарий от Rootlexx

Не, явно не то. Удалённый код просто включал xcb как дефолтный бэкенд на гноме. Ты сделал это руками через QT_QPA_PLATFORM=xcb и это не помогло. Видимо флэтпак, старающийся перекрыть возможность контейнеризированного приложения тырить данные, просто не позволяет ему коннектиться к X11. Отключение доступа к вейланду средствами флэтпака похоже снимает запрет на доступ к x11.

khrundel ★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.