PyQt5 apps do not use system display preferences on Linux

[BrenBarn]

Issue:

Python apps on Linux that use PyQt5 from conda-forge do not appear to inherit the display preferences set by the operating system. Instead they use some other ("default"?) settings, which make them look different from other programs on the user's computer. This is annoying for users of these apps.

The problem can be seen in apps such as Spyder. Here is a screenshot of Spyder running in a conda environment.

Here is a systemwide install of Spyder (via apt-get) installed on the same system:

You can see that the menus styles, button styles, fonts, etc. are not the same. The latter is using the settings set in the OS preferences, while the former isn't. Those examples are from Linux mint, but various reports of the problem can be found around the internet (e.g., here, here, here and here). Many of these suggest that the problem is that because the conda pyqt is disconnected somehow from the system pyqt, it's not getting the themes right.

Is there any way to allow installing various versions of PyQt5 in separate conda environments, while still having those versions automatically obtain and honor systemwide appearance preferences?

As far as I can tell the problem exists for all Python apps using PyQt5 from conda. It appears to be present with pyqt in anaconda defaults channel as well, but I decided to raise an issue here in hopes some wise maintainers may have ideas about how to fix the issue. At the least, the problem does exist for PyQt5 obtained from this feedstock, so the issue is applicable here. Likewise I'm unsure whether this is a PyQt issue or a Qt issue but figured I'd raise it here to start. (A related issue was recently raised in the qt feedstock.) Please let me know if there's a better place to raise the issue.

[mingwandroid]

In all likelyhood any attempt to fix this would create more problems than it could ever solve (non-native look is not a serious problem and not worth spending time on, IMHO).

To fix it you would need to subvert our Qt libs to read system Qt config which would work to some extent while those configs are somewhat compatible, but as soon as one Qt version is updated to make the configs incompatible, everything will break.

If you want to use a Qt that integrates better with your system, I would suggest using your system Qt.

[BrenBarn]

Thanks @mingwandroid . I realize it's not a showstopper bug but it's irritating for end users of GUI apps that are installed via conda. One of the biggest advantages of Qt is the ability to get native-looking apps across different platforms.

What exactly is "system Qt config"? I've been trying to find information about that but had no luck. Is there any way that a third-party lib could be written to act as a shim to read config from system Qt (from within the conda environment) and pass it to the conda Qt? Is this info stored in a config file anywhere?

[mingwandroid]

"Qt config" isn't a proper noun here. I mean the files and content of those files that control the look and feel of Qt. They are scattered and ephemeral.

Each distro tweaks aspects of Qt, particularly around trying to make them integrate cohesively into their 'Desktop Experience'. Sometimes this involves config files and sometimes it involves patching Qt's source code (less frequently these days).

So these things are not a part of our Qt, nor can they be because they are different on each distro and they are often achieved via hacks that we should not entertain.

We don't have the luxury of being able to make our Qt work like your distro, because then it's not going to work like that on your friend's linux distro if it is different to yours.

I would honestly say that the risk of breakage from any attempt to make Qt read GUI settings from any system location (particularly since there's little likelihood the versions are even in sync) would make one of the already most difficult to maintain packages in our ecosystem tangibly worse, more difficult to maintain and more bug-prone as you are dynamically changing how our Qt behaves according to local conditions (system Qt) we are not in control of.

[hmaarrfk]

FWIW, to my knowledge, spyder from defaults used to have the intended behavior on Ubuntu 20.04.

However, I've configured my system to seriously prefer conda-forge so it is difficult for me to recreate.

conda has done what I used to think was impossible before. It is isn't inconceivable that we get this to work nicely :D.

[ccordoba12]

i think the main issue here is that conda-forge's Qt doesn't come with support for Gtk (you can pass a flag to Qt's build system for that). We took care of that with @mingwandroid in my old Anaconda days (and it seems it's still in place, at least according to @hmaarrfk).