Linux Desktop Integration

[hmaarrfk]

Comment:

This is a tracking issue for the many attempts at integrating qt "seamlessly" into the linux desktop.

Qt5

• GTK3 Integration -- https://github.com/conda-forge/qt-gtk-platformtheme-feedstock
  • One of 3 4 attempts will likely get merge (soon?).
  • CDT-first - Gtk3 integration using CDT s #105
  • Subpackage for gtk3 plugin - gtk3 subpackage for better desktop on linux #98
  • plugin shipped, but not GTK3 dependencies - Add gtk3 but no deps #118
  • Totally separate package: Qt-GTK3 - attempt at creating distinct package for platform plugins staged-recipes#22086
  • aarch64 + ppc64le Rerender for COS7 and build aarch and ppc64le qt-gtk-platformtheme-feedstock#2
• Wayland integration -- https://github.com/conda-forge/qt-wayland-feedstock
  • Xref: Linux Qt missing Wayland QPA plugin #116
  • Attempt at build: Try wayland plugin #119
  • Needs wayland: Wayland recipe staged-recipes#22067
  • As a plugin: Qt wayland (no X11 cdts) staged-recipes#22071
    • KDE has patched this quite a bit: Qt wayland with kde patches staged-recipes#22078
    • Build with KDE patches? qt-wayland-feedstock#2
  • Rebuidl for aarch and ppc64le qt-wayland-feedstock#1
• Gnome Plugin
  • This seems to be necessary to get nice looking window decorations on gnome. -- Needs qt-wayland
  • https://www.reddit.com/r/gnome/comments/w27f63/why_window_decoration_waylandqt_looks_different/
  • https://github.com/FedoraQt/QGnomePlatform
  • Add adwaita-qt and other qt-gnome integration plugins staged-recipes#22072
• xkeyboard-config: xkeyboard-config missing dependency -- unable to use qt with wayland #117
  • Add xkeyboard-config as dependecy libxkbcommon-feedstock#20
• Write a few sentences about which packages to include for desktop integration.

qt6

• GTK Integration -- Try to build for qt6 qt-gtk-platformtheme-feedstock#6
• Wayland integration-- Qt6 build qt-wayland-feedstock#9
• Gnome Plugin -- Qt6 build qgnomeplatform-feedstock#3
  • Qt6 build adwaita-qt-feedstock#2

PS. I'm not familiar with desktop environments other than GTK, so I apologize if I missed anything.

[hmaarrfk]

@ccordoba12 sorry for having this conversation in a few different places but, I do think it is a little more than just "gtk3" integration.

In #98 (comment) you raised the concern that users would have to "opt in" for this kind of integration.

I do know that I don't want to increase the packaging complexity of qt. To me this means really trimming down each qt-recipe to the bare minimum. There are a few bugs that I keep hitting with multiple output recipes, so I would really like to avoid that approach. I would much prefer using different feedstocks for each subcomponent of qt, especially things like theming.

I'm not sure how we would do this (reliably), without some kind of opt-in.

We need to detect:

• X11 vs Wayland
• GTK vs KDE vs Other

There seems to be a few things the users would be interested in integrating, but conda (to my knowledge) doesn't have great visibility into those system decisions.

I guess my question is:

• Is the automatic enabling of this desktop integration important for you at this stage?

I would prefer having well organized packages with minimal dependencies and waiting a little longer to get "better system detection". My main concerns with adding more "features" to a "core" package are expressed in conda-forge/conda-forge.github.io#1894

[ccordoba12]

Is the automatic enabling of this desktop integration important for you at this stage?

Well, I don't want to block your efforts on this direction (which I find really valuable), so if you think the automatic approach is harder to maintain, then I'm fine with it. My main concern was that non-experienced Linux users, and those that don't know that these extra features are available as Conda-forge packages, would never use them.

I would prefer having well organized packages with minimal dependencies and waiting a little longer to get "better system detection".

Ok, no problem. Perhaps conda could recognize packages such as __kde or __gnome in the future (similar to the current __win or __unix ones) to automatically add these extra Qt packages.

[h-vetinari]

There are a few bugs that I keep hitting with multiple output recipes, so I would really like to avoid that approach.

I maintain several multi-output recipes without much troubles. Which (kind of) bugs do you have in mind?

Just a sidenote though; since you're doing almost all of the work, if you prefer separate feedstocks and it works, why not!

[hmaarrfk]

I just can't debug multiple output recipes:

git clone git@github.com:conda-forge/opencv-feedstock.git

Apply the following patch to get rid of one rendering problem

diff --git a/recipe/meta.yaml b/recipe/meta.yaml
index 1fa2d76..3e1e958 100644
--- a/recipe/meta.yaml
+++ b/recipe/meta.yaml
@@ -95,7 +95,7 @@ requirements:
     # Specify lgpl version of ffmpeg so that there are
     # no quesitons about the license of the resulting opencv
     # binary
-    - ffmpeg {{ ffmpeg }}=lgpl_*
+    - ffmpeg
     - qt-main                             # [not osx and not ppc64le]
     - liblapacke
     - liblapack

conda debug -m .ci_support/linux_64_numpy1.20python3.9.____cpython.yaml recipe/

Returns

More than one output found for this recipe (['/home/mark/mambaforge/conda-bld/debug_1676897807185/linux-64/libopencv-4.7.0-py39h2ca4621_1.tar.bz2', '/home/mark/mambaforge/conda-bld/debug_1676897807185/linux-64/opencv-4.7.0-py39hf3d152e_1.tar.bz2', '/home/mark/mambaforge/conda-bld/debug_1676897807185/linux-64/py-opencv-4.7.0-py39hcca971b_1.tar.bz2']).  Please use the --output-id argument to filter down to a single output.

and I just don't know the syntax to select an output id. I've tried so many different combinations.

To debug qt, you really need to be careful about system libraries and tools that are installed, so you need to use these debug environments.

[hmaarrfk]

For those interested in GTK integration, @jschueller @ccordoba12 @Tobias-Fischer a review of conda-forge/staged-recipes#22086 would be appreciated.

You can build the package locally quite quickly and test it out yourself. or you can copy it from https://anaconda.org/mark.harfouche/qt-gtk-platformtheme

[Vanuan]

I wonder how are conflicts resolved. For example, if Qt relies on a specific version of libfontconfig, while gtk3 which is provided with a host uses a different libfontconfig. Does qt use system libraries as well? Is it linked with system libraries statically? How are symbol conflicts resolved?

[hmaarrfk]

To be honest, i'm not sure how the symbols are solved. I am pretty set personally on pushing forward with: conda-forge/staged-recipes#22086

since I think it is easier to test, and to "roll back" in case of any mistake.

You should be able to test it with 5.15.6 at least from https://anaconda.org/mark.harfouche/qt-gtk-platformtheme

and we can move forward to updating it on conda-forge when it is merged through.

qt from conda-forge currently uses system libraries for X and OpenGL, though it has been proposed in #115 and the related PRs to move away from system X11 alltogether.

[BrenBarn]

Would this also theoretically handle issues like conda-forge/qt-feedstock#154 and conda-forge/pyqt-feedstock#87 ? (Not that I have the remotest idea how they would be solved :-) )

[hmaarrfk]

Yes. I think both those issues should be resolved by installing the first package on that list.

[BrenBarn]

Okay, thanks. Would that only be for Gnome/GTK? Is the postscript at the end of the list meant to suggest that some similar package would be required for KDE but we don't know yet what package that might be?

[hmaarrfk]

Correct. No computer i manage uses anything other than ubuntu with Gnome.

I know nothing about other desktop environments

[Vanuan]

@BrenBarn The plugin corresponding to QGnomePlatform is called KDEPlatformTheme: https://github.com/KDE/plasma-integration

There's also some useful information about file chooser here:
https://github.com/flatpak/xdg-desktop-portal

Apparently, it uses DBus messaging to open platform specific file dialog using freedesktop protocol schemas.
Not sure why it can't be a separate plugin. Probably to simplify deployment: instead of having dependencies between plugins, it's easier to just deploy one plugin that contains everything.

Or maybe it's just flatpak specific. But snap uses them as well: https://snapcraft.io/docs/xdg-desktop-portals

[hmaarrfk]

Not sure why it can't be a separate plugin

I think it can be a separate plugin from the GTK plugin. Is there some indication that it cannot.

I kept the GTK plugin outside of the current qt-main package to avoid an explosion of dependencies.

I think it should be doable with the KDE plugin too.

[Vanuan]

No, I meant why would QGnomePlatform and KDEPlatformTheme developers decided to embed the xdg-desktop-portal plugin (included in qtbase).

I think I've got it. You can't run both platform theme plugins at the same time. So if you want both GNOME styling/fonts and desktop portals you need them to be in a single platform theme plugin as there can only be a single platform theme running.

And since you can't link to a platform theme plugin as a library (due to an inherent flaw in native binaries as opposed to libraries in scripting languages), they've decided to just copy paste it.

[hmaarrfk]

To integrate with:

• Ubuntu + X11 + qt5

mamba install qt-main qt-gtk-platformtheme

• Ubuntu + Wayland + qt5

mamba install qt-main qt-wayland qgnomeplatform qt-gtk-platformtheme

• Ubuntu + X11 + qt6

mamba install qt6-main qt6-gtk-platformtheme

• Ubuntu + Wayland + qt6

mamba install qt6-main qt6-wayland qgnomeplatform6 qt6-gtk-platformtheme

[hmaarrfk]

Update: it seems that the qgnomeplatform is now no longer maintained or active.

To integrate with:

• Ubuntu + qt5

# X11
mamba install qt-main qt-gtk-platformtheme
# With wayland
mamba install qt-main qt-wayland qt-gtk-platformtheme

• Ubuntu + qt6

# X11 only
mamba install qt6-main qt6-gtk-platformtheme
# With wayland
mamba install qt6-main qt6-wayland qt6-gtk-platformtheme