Follow-up from #plasma on Freenode. We've been looking into an issue that AppImage users have had to face for a long time today, and it turned out to be a bug in Plasma. When integrating an AppImage, a desktop file and one or more icons are copied into ~/.local/share/{applications,icons}, respectively. These directories are "monitored" by Plasma. Plasma correctly detects the new desktop file, as there's a new entry in the launcher. However, the icon is missing. To fix the issue, you have to restart the plasma shell somehow (e.g., by logging out and in again). The reason is that Plasma, on startup, tries to list all directories in ~/.local/share/icons and starts watching them. If these directories don't exist, changes won't be recognized until plasmashell is restarted. While initializing, it now finds directories there to monitor. This behavior has apparently been introduced by https://phabricator.kde.org/R135:f9e5b852faa78f6d67615ea3c435b10b393cdaa5. A workaround for older versions of KDE for https://github.com/TheAssassin/AppImageLauncher will be to create all possible directories ~/.local/share/icons/hicolor/<all resolutions + scalable>/apps, and have the user restart plasma once then to permantently fix this issue. This is, however, just a workaround. Please fix Plasma upstream to watch these directories even if they're not existing (yet) during startup.
Apparently, creating ~/.local/share/icons seems to do the job. I don't have to change AppImageLauncher (or AppImageKit, where libappimage is developed), but add a note about Plasma's current behavior.
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).
(In reply to TheAssassin from comment #1) > Apparently, creating ~/.local/share/icons seems to do the job. I don't have > to change AppImageLauncher (or AppImageKit, where libappimage is developed), > but add a note about Plasma's current behavior. So I would have to correct my statement from yesterday here, by what I now found about KIconTheme being the actual effective code: just ~/.local/share/icons is not enough, it also needs to be the base dirs of each theme used, like ~/.local/share/icons/hicolor, which need to be present to not be skipped. (BTW, make sure not to hardcode ".local/share", but use ${XDG_DATA_HOME})
Git commit a0ab02c05205e25096c4916f92fc5501d7040e1a by Kai Uwe Broulik. Committed on 23/08/2018 at 09:31. Pushed by broulik into branch 'master'. [Icon Item] Watch KIconLoader icon change when using QIcon QIcon is rendered through KIconLoader instead of e.g. Plasma::Svg. This means we need to recreate the pixmap when the icon theme changes. Differential Revision: https://phabricator.kde.org/D14990 M +12 -0 src/declarativeimports/core/iconitem.cpp M +1 -0 src/declarativeimports/core/iconitem.h https://commits.kde.org/plasma-framework/a0ab02c05205e25096c4916f92fc5501d7040e1a
> just ~/.local/share/icons is not enough, it also needs > to be the base dirs of each theme used, like ~/.local/share/icons/hicolor Can this behavior be changed so that these don't need to be pre-existing? That would be great since then icons would work without having to exist the session beforehand.
As of now, we can get icons on desktop files to be rendered correctly in the Dolphin file manager but not in the various KDE application launchers, unless the user logs out and logs in again. Please see the screenshots for an illustration: Not working - https://user-images.githubusercontent.com/2480569/50489108-c354c800-09fd-11e9-8fd5-2932434f606b.png Working - https://user-images.githubusercontent.com/2480569/50489112-c5b72200-09fd-11e9-93f6-c119244a1f91.png Please change the app launchers to that they display the icons immediately without the user having to log out and log in again, similar to what Dolphin does. Reference: https://github.com/AppImage/libappimage/issues/29#issuecomment-450197431