Open hmaarrfk opened 1 year ago
@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 https://github.com/conda-forge/qt-main-feedstock/pull/98#issuecomment-1400663240 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:
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:
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 https://github.com/conda-forge/conda-forge.github.io/issues/1894
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.
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!
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.
For those interested in GTK integration, @jschueller @ccordoba12 @Tobias-Fischer a review of https://github.com/conda-forge/staged-recipes/pull/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
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?
To be honest, i'm not sure how the symbols are solved. I am pretty set personally on pushing forward with: https://github.com/conda-forge/staged-recipes/pull/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 https://github.com/conda-forge/qt-main-feedstock/pull/115 and the related PRs to move away from system X11 alltogether.
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 :-) )
Yes. I think both those issues should be resolved by installing the first package on that list.
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?
Correct. No computer i manage uses anything other than ubuntu with Gnome.
I know nothing about other desktop environments
@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
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.
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.
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
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
Comment:
This is a tracking issue for the many attempts at integrating qt "seamlessly" into the linux desktop.
Qt5
34 attempts will likely get merge (soon?).qt6
PS. I'm not familiar with desktop environments other than GTK, so I apologize if I missed anything.