Removing the QIcon::setFallbackThemeName("breeze"); line in setBreezeFallback() fixes the problem

I debugged this a bit.

The reason this fails is because the call to QIcon::setFallbackThemeName causes QIconLoader::ensureInitialized to be called, which sets up the internal configuration. At this point, however, the platform theme is not yet loaded to m_system_theme is empty.

By commenting out the call, the QIconLoader is only initialized after the platform theme got loaded and it works as expected.

Hi there, I'd like to bump this report, confirming that I'm also getting the issue.

Albert launcher (https://github.com/albertlauncher/albert) seems to be using QIcon::themeName to get user's preferred icon theme, and due to it returning empty string, Albert ends up failing in displaying the icons using user's preferred icon theme.

A relevant bug report in their Git repo can be found here: https://github.com/albertlauncher/albert/issues/778, along with some other people confirming they also encountered the issue.

In my application, I have a simple test for empty QIcon::themeName(), in which case I set a fallback theme name. The reason is that on other platforms (Windows etc.), using theme icons with fallback files in qrc *only* works when a theme name is set.[1]

Now with current KDE, Qt this leads to my application to set the false theme name and ignore desktop icons. This means, there is quite a few cross-platform applications out there with this problem.

[1] https://bugreports.qt.io/browse/QTBUG-16697

I can confirm this. I have just wasted something like 3 hours with GDB to come to the same conclusion already found in this bug report.

This completely breaks icon theming in Trojitá, because Trojitá has a custom icon loader wrapper that does this:
https://cgit.kde.org/trojita.git/tree/src/UiUtils/IconLoader.cpp#n50

Due to QIcon::themeName() being empty, ":/icons/%1/%2.svg" expands to ":/icons//iconname.svg", which happens to be the fallback location ":/icons/iconname.svg", and so it thinks the fallback icon is the override icon and wrongly prefers it to the theme.

Should the Plasma platform plugin call QIconLoader::updateSystemTheme()?

It looks like the same bug was reported to https://bugreports.qt.io/browse/QTBUG-74252 – I have cross-linked the 2 reports.

Is there anybody here who can answer my question:
Should the Plasma platform plugin call QIconLoader::updateSystemTheme()? Or should this maybe even be done somewhere within Qt itself (after loading a platform plugin?), as hinted at in https://bugreports.qt.io/browse/QTBUG-74252 ?

We need SOME way to fix this, sooner rather than later (this completely breaks theming in some applications and it has been open for over a year!), and the obvious fix (reverting the KIconThemes addition) does not look like the correct fix to me.

I would be willing to test and submit a fix, if people tell me (here or at Qt upstream) where the fix should go.

Kevin, can you confirm Albert's comment in QTBUG-74252 that it works correctly with Qt 5.14?

I can neither confirm nor disprove that at this time, because we do not have Qt 5.14 packaged in Fedora yet.

At most, I could try Qt 5.13.2 with some extra effort (either upgrading my notebook from Fedora 30 to 31 or rebuilding Qt 5.13.2 for Fedora 30, unless it already sits in a Copr somewhere), but 5.14 is not even in Rawhide yet.

(Even if I test fixes, the way I generally go at it is that I develop them against the version that is packaged, test them by adding them as patches to the SRPM, then (before upstreaming them) forward-port them to whatever branch upstream wants patches submitted against.)

No, it doesn't work with Qt 5.14

albert -r
        Albert version: 0.16.1
            Build date: Mar 30 2020 02:58:04
            Qt version: 5.14.1
  QT_QPA_PLATFORMTHEME: 
       Binary location: /usr/local/bin/albert
                   PWD: /home/jchun/Documents/Projects
                 SHELL: /bin/bash
                  LANG: en_US.UTF-8
      XDG_SESSION_TYPE: x11
   XDG_CURRENT_DESKTOP: KDE
       DESKTOP_SESSION: /usr/share/xsessions/plasma
   XDG_SESSION_DESKTOP: KDE
                    OS: KDE neon User Edition 5.18
     OS (type/version): neon/18.04
             Build ABI: x86_64-little_endian-lp64
  Arch (build/current): x86_64/x86_64
 Kernel (type/version): linux/5.3.0-45-generic

Bumping this to confirm it doesn't work with 5.14

This is the Qt fix that should fix this:
https://codereview.qt-project.org/c/qt/qtbase/+/302581

5.12 LTS backport:
https://codereview.qt-project.org/c/qt/qtbase/+/302582

I confirm the Qt commit fixes the issue

Git commit 899c0f7fa457d77f4b53f8540e22290da862d57d by Igor Poboiko.
Committed on 04/06/2020 at 22:03.
Pushed by poboiko into branch 'master'.

[KMainWindow] Invoke QIcon::setFallbackThemeName (later)

Summary:
This is alternative approach to {D22488} and commit 4214045 to KIconThemes.
Okular (and most - if not all - KDE apps) inherit KMainWindow, so KDE apps
should have breeze icons). KMainWindow ctor should be early enough so no icons
are yet loaded, but late enough so QGuiApplication is already inited.

This should be followed by reverting commit 4214045 in KIconThemes.

Original problem description (by @mart):
invoking QIcon::setFallbackThemeName at QCoreApplication ctor
with Q_COREAPP_STARTUP_FUNCTION breaks the internal status of
QIconLoader as it instantiates it before the QPlatformTheme,
but QIconLoader depends from QPlatformTheme to be already instantiated
otherwise it won't load correctly, thus breaking icon loading
in QtQuickControls2 styles, such as Material and Fusion
see https://bugreports.qt.io/browse/QTBUG-74252

Test Plan:
Don't have GTK3 QPA plugin, so cannot test it yet.
I would appreciate if someone helped me with testing :)

Reviewers: aacid, mart, broulik

Subscribers: mart, kde-frameworks-devel

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D29826

M  +17   -0    src/kmainwindow.cpp

https://invent.kde.org/frameworks/kxmlgui/commit/899c0f7fa457d77f4b53f8540e22290da862d57d