Disable Wayland access

[freakboy3742]

In my testing, PySide6 doesn't display window chrome if the wayland socket is open. Ultimately, we're going to want to make these permissions user-configurable; but for now, a set of defaults that work for the demo apps seems preferable.

This also re-orders the build so that bootstrap and resources (which are less likely to change) occur earlier, so they (in theory) should result in faster builds due to not spoiling the build cache.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[rmartin16]

Testing on debian 11 with system python 3.9, I noticed that pip was still installing PySide6==6.2.4. However, this was resolved if I upgraded pip before the install.

Do you want to add a statement to upgrade pip?

[freakboy3742]

That's odd - the version of pip should be installed at the end of the build. I thought ensurepip always resulted in the most-recent pip... but if it doesn't, then yeah - I guess we should update pip before performing package installs.

[freakboy3742]

(I'll push an update shortly)

[rmartin16]

For posterity....(I added -vv for my debugging):

[21:23:20] ========================================================================                                                                                subprocess.py:637
           Building module app_packages in /home/user/github/beeware/briefcase/tmp/pyside6test/linux/flatpak/pyside6test/.flatpak-builder/build/app_packages-1     subprocess.py:637
           ========================================================================                                                                                subprocess.py:637
           Running: mkdir -p /app/briefcase/app_packages                                                                                                           subprocess.py:637
           Running: /app/bin/python3 -m pip install -vv --no-cache-dir -r requirements.txt --target /app/briefcase/app_packages                                    subprocess.py:637
           Using pip 20.2.3 from /app/lib/python3.9/site-packages/pip (python 3.9)                                                                                 subprocess.py:637

[rmartin16]

I spent way too long looking at this...

When you start the flatpak with Qt debugging enabled, you find this error:

$ flatpak run --env=QT_DEBUG_PLUGINS=1 com.example.pysidetest
.
.
.
qt.core.plugin.factoryloader: Got keys from plugin meta data QList("gnome", "gtk3", "qgnomeplatform")
qt.core.plugin.factoryloader: checking directory path "/app/briefcase/app_packages/PySide6/Qt/plugins/wayland-decoration-client" ...
qt.core.plugin.factoryloader: looking at "/app/briefcase/app_packages/PySide6/Qt/plugins/wayland-decoration-client/libbradient.so"
qt.core.plugin.loader: Found metadata in lib /app/briefcase/app_packages/PySide6/Qt/plugins/wayland-decoration-client/libbradient.so, metadata=
{
    "IID": "org.qt-project.Qt.WaylandClient.QWaylandDecorationFactoryInterface.5.4",
    "MetaData": {
        "Keys": [
            "bradient"
        ]
    },
    "archlevel": 1,
    "className": "QWaylandBradientDecorationPlugin",
    "debug": false,
    "version": 394240
}


qt.core.plugin.factoryloader: Got keys from plugin meta data QList("bradient")
qt.core.plugin.factoryloader: checking directory path "/app/bin/wayland-decoration-client" ...
qt.core.library: "/usr/share/runtime/lib/plugins/QGnomePlatform-decoration/wayland-decoration-client/libqgnomeplatformdecoration.so" cannot load: Cannot load library /usr/share/runtime/lib/plugins/QGnomePlatform-decoration/wayland-decoration-client/libqgnomeplatformdecoration.so: (/usr/share/runtime/lib/plugins/QGnomePlatform/lib/libadwaitaqt6.so.1: undefined symbol: qt_resourceFeatureZstd, version Qt_6)
qt.core.plugin.loader: QLibraryPrivate::loadPlugin failed on "/usr/share/runtime/lib/plugins/QGnomePlatform-decoration/wayland-decoration-client/libqgnomeplatformdecoration.so" : "Cannot load library /usr/share/runtime/lib/plugins/QGnomePlatform-decoration/wayland-decoration-client/libqgnomeplatformdecoration.so: (/usr/share/runtime/lib/plugins/QGnomePlatform/lib/libadwaitaqt6.so.1: undefined symbol: qt_resourceFeatureZstd, version Qt_6)"
Could not create decoration from factory! Running with no decorations.

From what I've gathered about qt_resourceFeatureZstd, this may imply a fundamental difference in expectations about how PySide6 is compiling Qt and how QGnomePlatform-decoration is expecting things to be compiled. It makes me wonder if instead of using the PySide6 wheel, we set things up such that PySide6 uses the Qt available in the flatpak kde platform, perhaps this issue would be avoided. However, I also feel quite a bit in over my head.

Anyway, as for avoiding Wayland and forcing X11....what if instead of letting Qt try to use Wayland, fail, and fallback to X11, we just tell Qt to use X11 from the beginning. If I add - --env=QT_QPA_PLATFORM=xcb to finish-args (and remove the socket for Wayland altogether), this achieves effectively the same outcome but in a bit more direct way I think.

Thoughts?

[rmartin16]

Also, in looking for prior art for putting PySide6 in to a Flatpak, I only found the information...which may offer inspiration in general for our goals.

Coolero: https://github.com/flathub/org.coolero.coolero
An apparent attempt to provide a Flatpak base for using PySide with Flatpak: https://github.com/tinywrkb/flathub/blob/io.qt.PySide.BaseApp/io.qt.PySide.BaseApp.yaml

[freakboy3742]

Thoughts?

I got nothing :-)

My original hope was that Flatpak was going to be a more reliable cross-platform single binary solution than AppImage, but it's clearly... not. Or, if it is, it requires a lot more platform expertise that they're going to great efforts to not document.

This is essentially why I've been working on the deb backend recently - I get the very distinct impression that the "single binary download" goal is near unattainable on Linux - or, at least, it comes with so many caveats that it's not really something we can recommend for general consumption.

So - my inclination is that we either merge this, as is, knowing that it's very imperfect, but marginally better than before; or we close it, document the limitations of the flatpak backend, and focus on getting deb/rpm/pacman backends working so we can look at adopting "native platform packaging" as the default for Linux.

Thoughts? :-)

[rmartin16]

my inclination is that we either merge this, as is

That's fair; I don't think either of these solutions are "great" by any means; so, I'm fine with merging this and disallowing access to Wayland by default given these issues with PySide. Ive also confirmed that Wayland can easily be re-enabled by end-users with flatpak run --socket=wayland ... or using Flatseal.

My primary takeaway from this exercise is packaging PySide in to a Flatpak is a largely unexplored area.