https://bugs.kde.org/show_bug.cgi?id=397109
Friedrich W. H. Kossebau <kosse...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kosse...@kde.org
--- Comment #2 from Friedrich W. H. Kossebau <kosse...@kde.org> ---
I looked some more into this. Seems the issue is not that simple to fix, as
there are some more layers which do caching and would need to be changed.
Too much right now for me to continue.
Let me dump here my findings for now:
For each QIcon created via QIcon::fromTheme internally a QIconEngine instance
is created by asking the platform theme plugin for one. In case of Plasma that
platform theme plugin is KdePlatformThemePlugin, coming from the repo
"plasma-integration".
That one delivers an instance of the QIconEngine subclass KIconEngine, as
implemented in KDE Frameworks' "KIconThemes" module.
KdePlatformThemePlugin also implements calculating a value for the theme hint
QPlatformTheme::IconThemeSearchPaths. Which is touched in the commit mentioned
and linked in the comment #1 by TheAssasin.
(Just, as it turns out, KIconEngine completely ignores that value and the
QIcon::themeSearchPaths() in general, instead always doing its own look-up
scheme, more below)
The value for QPlatformTheme::IconThemeSearchPaths is used only via the static
QIcon::themeSearchPaths(). That one forwards the query to the Qt-internal
QIconLoader::themeSearchPaths() which itself will get the default value from
the platform theme, unless the user has set some custom paths via
QIcon::setThemeSearchPaths(...).
QIconLoader will cache the result (and also extends it by ":/icons" to support
resource files), only refetch it from the platform theme plugin if meanwhile
the user has reset the paths by setting an empty list.
-> path not reported on first query, will not be seen afterwards (unless reset
triggered via QIcon::setThemeSearchPaths(emptyList();)
The genericunix platform theme plugin coming with Qt itself, when calculating a
value for QPlatformTheme::IconThemeSearchPaths it checks any possible paths if
they already exist (QFileInfo(path).isDir()) and only returns those.
-> path not existing at read, will not be seen afterwards.
KIconEngine internally creates a tree of KIconTheme objects (for supporting the
icon theme inheritance aspect of the xdg icon spec). Creation of KIconTheme
objects is delayed until needed (e.g. like having to fallback to "hicolor"). In
their construction they look up currently existing dirs used for their theme,
then cache that information.
The dirs which are checked here are selected without looking at the value of
QIcon::themeSearchPaths().
-> path not existing at creation of KIconTheme object, will not be seen
afterwards.
QStandardPaths::standardLocations(type) at least in recent Qt versions prepends
the user/writable dir to the returned list. So e.g. for GenericDataLocation on
Linux it will be first XDG_DATA_HOME, then the items of XDG_DATA_DIRS. The
returned list contains any dirs without being checked for existance.
INITIAL CONCLUSION:
The reason for only returning existing paths makes sense for runtime
performance reason, it saves doing "stat" calls on the filesystem for paths
which are already known not to exist (assuming a static system).
At the same time this snapshotting of existing icon filders at process start
though harms long-running processes like workspace shells, which want to pick
up new resources during their lifetime, e.g. when new applications/plugins are
installed.
The actual responsible code for the bug reported here with Plasma itself seems
to be in the KIconTheme code, which only picks up base icon directories which
exist when the object is created.
No instant idea how to solve this. Could be done by either introducing some
signalling on the creation of new icon base dirs (like ${XDG_DATA_HOME}/icons
as in this bug report), to trigger the addition of that dir to the places
looked up (might be a race condition though if something else is already trying
to use the new icon).
Or done by always also trying to read from any candidate paths, unless that is
too expensive (e.g. as XDG_DATA_HOME would be always checked first, even if not
existing).
--
You are receiving this mail because:
You are watching all bug changes.
