search

FreeCAD / FreeCAD-Bundle

Stand-alone repo to Build and Deploy installable FreeCAD images
https://freecad.org
GNU Lesser General Public License v2.1
224 stars 58 forks source link

Bundle QGnomePlatform theme #154

Open Vanuan opened 1 year ago

Vanuan commented 1 year ago

Is it possible to bundle: https://github.com/FedoraQt/QGnomePlatform ?

Should be put to ${QT_DIR}/plugins/platformthemes/

Maybe as easy as adding qgnomeplatform to mamba install? https://github.com/conda-forge/staged-recipes/pull/22072#issuecomment-1436042316

Vanuan commented 1 year ago

Or should it be rather added to https://github.com/FreeCAD/FreeCAD_Conda ?

Vanuan commented 1 year ago

https://anaconda.org/mark.harfouche/qt-gtk-platformtheme conda install -c mark.harfouche qt-gtk-platformtheme

luzpaz commented 1 year ago

Is this something that the flatpak and snap packages can also benefit from @Vanuan ?

adrianinsaval commented 1 year ago

how much additional storage would this take? if it would be done I would like KDE's breeze theme to be included too

Vanuan commented 1 year ago

@luzpaz I'm not sure. AFAIK, those have Qt runtime bundled separately. QGnomePlatform currently is linked to a specific Qt version, so it's more a part of a Qt runtime rather than an app. Having QGnomePlatform bundled with a flatpak/snap app would mean requiring a specific version of Qt. I'm not an expert. It looks like FreeCAD already requires a specific Qt version. But I'm still not sure if those will be binary compatible as it uses some private Qt API. It would be better if maintainers of corresponding Qt snap/flathub packages provided platform plugins as an option to be consumed by apps. E g. https://github.com/flathub/org.kde.PlatformTheme.QGnomePlatform

Vanuan commented 1 year ago

@adrianinsaval QGnomePlatform takes 150kiB compressed, 500 kiB uncompressed. But it depends on adwaita-qt for dark/light theme, which is additional 50/200 kiB.

Vanuan commented 1 year ago

@adrianinsaval Please don't confuse DE themes with Qt platform theme plugins. There is KDEPlatformTheme which provides better integration of a Qt app with Plasma (which is a KDE counterpart to GNOME). The Breeze is a default Plasma theme, a KDE counterpart to Adwaita. Adwaita is a theme to give GTK apps a "gnomy" look and feel. QGnomePlatform depends on GTK3 but can work without Adwaita. It uses dbus to get corresponding settings like font sizes, so it's quite isolated. It depends on Adwaita-Qt which is a Qt implementation of Adwaita.

I don't know what bundling KDEPlatformTheme involves, whether it provides breeze and whether it exists in conda. Please do your own research and create a separate issue.

adrianinsaval commented 1 year ago

@adrianinsaval QGnomePlatform takes 150kiB compressed, 500 kiB uncompressed. But it depends on adwaita-qt for dark/light theme, which is additional 50/200 kiB.

is there a conda package for this and can you indicate which ones? or even better, make a PR adding them here: https://github.com/FreeCAD/FreeCAD-Bundle/blob/master/conda/linux/create_bundle.sh

also does that storage space include all it's dependencies?

Vanuan commented 1 year ago

@adrianinsaval There is a conda package from the user channel, but not conda-forge. There's an open PR to merge the recipe in the staging channel. The main ticket discusses Linux Desktop integration in general which you might be interested in, but has no specific recipes for KDE.

I think one needs to test. The problem is that QGnomePlatform depends on GTK3 which is not currently bundled. And GTK3 depends on many system dependencies which are included in the FreeCAD AppImage. The conda recipe treats GTK3 as a host runtime dependency. So we need to test how to ensure compatibility between the bundled QGnomePlatform and the GTK on the host. It might be impossible but worth looking into. When the versions are exactly the same, it works.

Flatpak provides Freedesktop, GNOME and KDE runtimes which apps can depend on. The app should be built for this specific version of runtime using Flatpak SDK which is a set of dependencies a Flatpak app is linked with. Flatpak example. Freecad already uses the KDE runtime which is based on Freedesktop so it includes Gtk3.

Snap packages has a similar idea, providing Snapcraft extensions to distribute common requirements. The app which doesn't use such a mechanism will weight 33 MiB more. FreeCAD uses kde-neon extension which I'm not sure if included gtk.

It definitely needs more investigation. AppImage doesn't have such a mechanism, it allows the host dependencies to leak into the "container". Which sometimes may cause an app to crash if the versions are incompatible. I'm not sure why it is done this way, but it is what it is. Maybe we need to bundle Gtk3 and its dependencies as well, after all.

FreeCAD weekly currently weights almost 1 GiB, so bundling Gtk3 might not be a big deal. It's an inherent problem of all containerized environments: https://ludocode.com/blog/flatpak-is-not-the-future

Vanuan commented 1 year ago

Here's what AppImageKit author suggests:

So, there appear to be conflicting requirements. Either your app is fully isolated and only uses stable APIs such as POSIX and X/Wayland protocols, with its own appearance. Or your app uses additional desktop APIs, such as gtk3, which means updating for each linux distribution. At this stage, Linux Desktop doesn't have stable APIs such as WinAPI/UWP, Cocoa to make GUI apps independent of the particular Linux distribution.

So, maybe the solution is to build a particular AppImage that will conditionally load a Qt platform theme plugin depending on the distribution. This will require building several QGnomePlatform plugins, each with its own set of non-conflicting gtk3 dependencies. Unfortunately, it will mean that there should be different versions of Qt dependencies.

Well, as you can see, the problem is that there's no clear boundary in desktop Linux between the GUI toolkit and the system-defined appearance. You either need to support multiple systems or give up the idea of a system-defined theme. A proper solution would be to introduce a new library/API that will standardize the rendering of toolkits. QGnomePlatform is the closest to achieving this. Too bad it still depends on gtk3. But there are certain things, such as file chooser that don't have GUI toolkit independent abstractions in Linux Desktop. Linux Desktop desperately needs a unifying GUI platform similar to what dbus and systemd did for daemons.

adrianinsaval commented 5 months ago

revisiting this I see qgnomeplatform is now in conda-forge. Installing qgnomeplatform in a conda environment also installs several other packages:

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    adwaita-icon-theme-43      |           unix_0         4.5 MB  conda-forge
    adwaita-qt-1.4.2           |       hbde21bd_1         291 KB  conda-forge
    at-spi2-atk-2.38.0         |       h0630a04_3         332 KB  conda-forge
    at-spi2-core-2.40.3        |       h0630a04_0         643 KB  conda-forge
    epoxy-1.5.10               |       h166bdaf_1         1.4 MB  conda-forge
    gtk3-3.24.40               |       h280cfa0_0         9.3 MB  conda-forge
    hicolor-icon-theme-0.17    |       ha770c72_2          14 KB  conda-forge
    qgnomeplatform-0.9.2       |       h8b7e3d8_1         215 KB  conda-forge
    qt-wayland-5.15.8          |       hca6e417_0        1012 KB  conda-forge
    wayland-1.22.0             |       h8c25dac_1         299 KB  conda-forge
    xorg-libxcursor-1.2.0      |       h0b41bf4_1          31 KB  conda-forge
    xorg-libxinerama-1.1.5     |       h27087fc_0          13 KB  conda-forge
    ------------------------------------------------------------
                                           Total:        18.0 MB

It does not seem to rely on the system gtk3 library. The "host" section in the recipe you linked before doesn't refer to system libraries, if I'm not mistaken it's related to using packages for the architecture of the host system during build since conda packages are often cross compiled for other architectures from an x86_64 machine.

So it might be possible to ship this after all but I'm not sure if it's really worth doing. We are probably moving towards having specific well designed stylesheets enabled by default in the future rather than keep relying on the system theme.