search

conda-forge / qt-main-feedstock

A conda-smithy repository for qt-main.
BSD 3-Clause "New" or "Revised" License
5 stars 29 forks source link

Linux Desktop Integration #120

Open hmaarrfk opened 1 year ago

hmaarrfk commented 1 year ago

Comment:

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

Qt5

qt6

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

hmaarrfk commented 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

ccordoba12 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Vanuan commented 1 year ago

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 commented 1 year ago

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.

BrenBarn commented 1 year ago

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 commented 1 year ago

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

BrenBarn commented 1 year ago

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 commented 1 year ago

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

I know nothing about other desktop environments

Vanuan commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

To integrate with:

hmaarrfk commented 5 months ago

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

To integrate with: