QIcon: don't rely on getting a null-icon in test

If a QPA-provided engine provides an "edit-cut" icon, then it won't be
null. We cannot reliably test that the icon came from the fallback theme
as the cacheKey of the icon doesn't change (the proxying to a different
theme is handled internally by the QThemeIconEngine).

That the cacheKey of a QIcon doesn't change even if the pixmaps we get
from it change is not a problem in practice; QIcon is a named container
for  transient graphical assets that might change for reasons outside of
Qt's control (such as color scheme, or display resolution).

Change-Id: I695e8ad0c8f0aec7f17a2c242e64b615178b78b5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This commit is contained in:
Volker Hilsheimer 2023-12-06 11:01:43 +01:00
parent 4e6f7ad26c
commit 76b58be4b8

View File

@ -722,10 +722,16 @@ void tst_QIcon::fromTheme()
QCOMPARE(i.availableSizes(), abIcon.availableSizes());
}
// Check that setting a fallback theme invalidates earlier lookups
QVERIFY(QIcon::fromTheme("edit-cut").isNull());
// Setting or changing the fallback theme should invalidate earlier lookups.
// We can only test this if the system doesn't provide an icon, because once
// we got a valid icon, it will be cached, and even if we proxy to a different
// engine when a fallback theme is set, the cacheKey of the icon will be the
// same.
const QIcon editCut = QIcon::fromTheme("edit-cut");
if (editCut.isNull()) {
QIcon::setFallbackThemeName("fallbacktheme");
QVERIFY(!QIcon::fromTheme("edit-cut").isNull());
}
// Make sure setting the theme name clears the state
QIcon::setThemeName("");