Icon Theme Installed but Nothing Changed: The Checklist

Your chosen icon theme is set in the desktop configuration. It should be in full effect by now. But it isn't. Some icons - often the launcher icons - stubbornly remain in their old style. You've been here before: restart the session, reboot, dive into your distro's packaging system... And yet something still looks off.

On most desktop environments, there's a hierarchical order to how icons are resolved and loaded. It's similar but not identical to how regular desktop themes work. And it can be even more finicky, especially when containerized apps, modified .desktop files, or time-worn cache states get in the way.

Why Icon Themes Can Be Selected But Not Appear

It can be deeply puzzling to have a theme selected and confirmed in your desktop configuration but see it only partially applied. This particular problem does not usually trace back to a failure to select or install the theme. Everything past that first selection is a separate routing step.

Where exactly is your desktop trying to load the icon from? There are competing icon directories to check, from user-specific paths to system-scoped ones and then into distributor/curated theme caches.

The reasons are not always the same, but they are often hierarchical: icons can be themed from system-wide files, then a fallback of icon themes installed system-wide. It appears that symbolically linked icons can override this and present in a different style altogether.

If you can find proof that an icon selection even initiated, you're way ahead - but icon theme routing failures are the reason themes are set and yet remain unapplied.

Check the Install Location First

The first diagnostic on the list is the wrong-directory failure: is the selected theme actually installed in the path it's expected to refer to?

This points to a hierarchy, from user-specific over to system-specific and then to distributions:

• <HOME>/.local/share/icons/
• <HOME>/.icons
• /usr/share/icons

Your user profile might have the full icon theme set in the desktop config. It might even have the cache built. But the theme itself can be completely missing from any of those paths - the fallbacks not kicking in, or the expectation that a fallback would adequately solve this cannot be verified.

When a theme is installed, where is it copied to? How do you browse or validate its components? Starting in a shell, do the usual locations have a full theme directory? Validate the index.theme file is in place and all the icon files and subdirectories expected.

On the Arch Linux discussion board, a user reported a case in which KDE Plasma appeared to have an icon theme applied on all menu entries, but not in launchers or folders. The desktop settings page showed the awaited theme to be in effect, but large sections were not applied.

Rebuild or Refresh the Icon Cache

Once you've confirmed the files are in place, there's a still common failure for them to be recognized: is gtk-update-icon-cache not recognizing the theme as valid or updated in its caches?

The gtk-update-icon-cache call is supposed to kick in when you install or modify an icon theme. But it can fail silently, or without full logging. It can also fail to clean up old caches on uninstall.

From the gtk-update-icon-cache manual page, the icon-theme.cache file contains cached information about the icons in the directory tree below the directory containing your index.theme file. This file is expected to be mmap()-able, optimizing for random lookups - but it may not contain current or complete information to begin with.

Running gtk-update-icon-cache -f -t /path/to/theme is recommended after installing an icon theme, according to the Arch Wiki, to build or rebuild the nearest icon-theme.cache.

Is the App Shipping Its Own Icon?

If you've found the right directory and rebuilt the cache, but still cannot see icons applied in a certain application, look at whether the app itself is the problem.

Snap applications might fail to update or recognize the new global theme as applied. They might be loading their own icons from /var/lib/snapd/desktop/applications/ - the launcher itself, in the .desktop file, could specify Icon=gtk-snap-icon. The solution there is manual, kicking up an editor rather than a reconfiguration: copy the .desktop file to ~/.local/share/applications/ and change the Icon= line.

After a Flatpak guide suggests that Flatpak applications may use an icon theme from the installed Flatpak runtime, rather than the host. It suggests installing the icon theme, again through Flatpak, for it to be available to Flatpak apps. There are audit logs and steps, but no primary-source verification of the exact relationship still available on access.

Check Sandboxed Packages

On environments like Flatpak, there are specific ways to make your icon themes available to installed Flatpak apps, separate from what applications on your host desktop access. For example:

flatpak install flathub org.kde.PaplirusIconTheme

A guide goes into these and other approaches. But it, too, falls short of confirming that the main effect of the command here is to expose the host's icon themes into the Flatpak environment, or only themed icons. It points to an obscure relationship that can explain some icon-hosting discrepancies, short of a document defining how host environments and Flatpak containerization expose or fail to expose icon themes.

Symbolic Icons vs Full Theme Coverage

Last of all, remember there's a step between setting a theme and seeing every icon in the desired style. Some icons may be "symbolic" or provided by the app itself, outside of your configured themes.

On the Arch Linux forums, a user reported an issue where fixing an "lxappearance cache problem" updated icons to the newest icon-theme cached, but also downgraded some of his icons in launcher menus (launcher menus, it so happens, can also be a common source of conflict themselves). This points to a downgrade in theming precedence, but whether symbolic linking was the cause, as a sub-step, was not definitive.

One takeaway here, at least, is that icon themes are not always intended to cover every icon. There is an "inherited fallback" order in icon theming, but it appears to resolve some icons from non-desktop-specified sources, not all.

Sources

• Ask Ubuntu — askubuntu.com
• Arch Linux Forums — bbs.archlinux.org