Mastering Thunar: Resolving Missing Icons for Specific .desktop Files in /usr/share/applications/

At revWhiteShadow, we understand the frustration that arises when your meticulously organized application launcher in the Xfce desktop environment presents a visual inconsistency, particularly when specific applications fail to display their associated icons within the Thunar file manager’s application menu. We have encountered a scenario on a Debian Buster system, running Xfce version 4.12 with Thunar version 1.8.4, where a select few .desktop files located in the /usr/share/applications/ directory stubbornly refuse to render their intended icons. This phenomenon, while seemingly minor, can disrupt the aesthetic harmony and intuitive navigation of your desktop. We are committed to providing you with a comprehensive understanding of this issue and actionable steps to rectify it, ensuring a polished and functional user experience.

Our investigation has pinpointed a peculiar pattern associated with the problematic .desktop files. Specifically, three entries within /usr/share/applications/ exhibit this icon display anomaly. Upon closer examination of their respective .desktop files, we’ve observed a distinct characteristic in how the Icon= line is defined. Unlike the majority of other applications in the same directory, which either specify a direct path to an icon file or utilize a generic icon name (such as Icon=xfwm4), these three applications employ a naming convention that appears to be directly derived from their application’s unique identifier or bundle name. The specific Icon= lines in question are:

  • Icon=ca.desrt.dconf-editor
  • Icon=org.gnome.Evince
  • Icon=org.gnome.Yelp

This observation is further supported by the fact that these are the only .desktop files in the /usr/share/applications/ directory that adhere to this particular naming convention for their Icon= entries.

A key piece of information that further deepens our understanding of this issue is that, despite the absence of icons within Thunar’s application listings, the Xfce Whisker Menu correctly displays the associated icons for these same applications. This suggests that the underlying icon data is present and accessible to the system, but Thunar’s specific method of querying or interpreting these icon names is encountering an impediment.

Our diagnostic efforts have also revealed that for each of these three problematic applications, multiple instances of their correct icons can be found within the /usr/share/icons/hicolor directory. This directory is a standard location for application icons, typically organized by size and resolution. The presence of these icons confirms that the graphical assets themselves are not missing; rather, the mechanism by which Thunar is instructed to locate and display them is the point of failure.

We have diligently performed the standard procedure for updating the icon cache. Executing the command gtk-update-icon-cache -f /usr/share/icons/hicolor/ as the root user, which is the recommended method for refreshing icon theme information, unfortunately, did not yield the desired results. This reinforces our suspicion that the issue lies not with a corrupted or outdated icon cache, but with the interpretation of the Icon= field within the .desktop files themselves.

It is important to note that our current setup utilizes the Tango icon theme within Xfce. We have no intention of altering this preferred aesthetic. Therefore, any solution we explore must be compatible with the existing icon theme, ensuring that the overall visual consistency of the desktop is maintained. While we acknowledge that a pragmatic workaround would be to manually edit each of the three .desktop files and explicitly provide the full path to the desired icon file (e.g., Icon=/usr/share/icons/hicolor/256x256/apps/dconf-editor.png), our primary goal is to understand the root cause of this discrepancy and explore more elegant, system-wide solutions if possible.

Understanding the Mechanics of .desktop File Icon Resolution in Xfce and Thunar

To effectively address the missing icon problem, it is crucial to delve into how desktop environments, and specifically Xfce and Thunar, resolve icon paths specified within .desktop files. These files serve as metadata containers for applications, providing information such as the application’s name, description, executable path, and, pertinently, its icon.

The Icon= key in a .desktop file can accept several formats:

  1. Absolute Path: This is a direct, fully qualified path to an icon file (e.g., Icon=/opt/my_app/icons/my_app.png).
  2. Relative Path: This path is relative to the directory containing the .desktop file. While less common for system-wide applications, it’s a possibility.
  3. Icon Name: This is the most common and flexible method. The system searches for an icon file with this name (often without an extension, as the system will look for common extensions like .png, .svg, .xpm) in various predefined icon theme directories.

The system’s ability to find an icon based on a name relies on a well-defined search path, which includes directories specified by the XDG_DATA_DIRS environment variable and locations within installed icon themes. The hicolor icon theme, as we’ve observed, is a fallback and general-purpose repository for icons that do not conform to specific theme naming conventions.

When an Icon= entry is simply a name like dconf-editor, the system consults the Freedesktop.org specifications for Desktop Entry files and Icon Theme naming. The system will typically look for the icon in a structure like:

/usr/share/icons/<icon_theme_name>/<size>/apps/<icon_name>.png

or

/usr/share/icons/hicolor/<size>/apps/<icon_name>.png

The gtk-update-icon-cache command is essential for creating or updating the .ico cache files that speed up icon lookups within these directories. However, if the .desktop file’s Icon= entry does not conform to the expected naming patterns that the icon theme engine or desktop environment can readily parse, the cache update alone will not resolve the issue.

The anomaly in our case, where Icon=org.gnome.Evince or Icon=ca.desrt.dconf-editor is used, suggests that the system might be expecting a more direct mapping or that the icon naming convention used by these specific applications is not being correctly interpreted by the default icon resolution mechanisms employed by Thunar in this particular Xfce version. The fact that the Whisker Menu does display the icons indicates that another part of the Xfce environment is successfully resolving these names. This could be due to a slightly different lookup logic or an earlier registration of these specific names within the Whisker Menu’s configuration.

Investigating Thunar’s Icon Resolution Logic and Potential Conflicts

Thunar, as the default file manager for Xfce, integrates closely with the desktop environment’s components. Its ability to display application icons in its “Applications” shortcut or similar views is usually powered by the same underlying libraries that populate menus in other Xfce applications. However, subtle differences in how these libraries are invoked or configured can lead to discrepancies.

The use of reversed domain name notation for application identifiers, like org.gnome.Evince or ca.desrt.dconf-editor, is a common practice for ensuring uniqueness, particularly in the GNOME ecosystem. While this convention is widely adopted, the interpretation of these names as direct icon references might be where the divergence occurs. It’s possible that Thunar’s internal logic, or the specific Freedesktop.org standards it adheres to for icon lookups based on such names, is more rigid or expects a slightly different format when directly querying for an icon associated with a .desktop file.

Given that the icons are present in /usr/share/icons/hicolor/ and are correctly rendered elsewhere, we can infer that the system has a mapping between these reversed domain names and the actual icon files. The challenge lies in surfacing this mapping correctly within Thunar’s specific context.

A key question arises: does Thunar directly query the .desktop file for its Icon= value and then attempt to resolve that value against the installed icon themes, or does it rely on a broader system-level application registry that might perform additional lookups or canonicalizations? The behavior observed suggests the former might be more dominant in this scenario, or that the latter’s cached results are not being fully leveraged by Thunar in the same way as by the Whisker Menu.

Troubleshooting Steps for Icon Display Issues in Thunar

Let’s proceed with a methodical approach to diagnose and resolve the missing icon issue. Our primary aim is to identify why Thunar is failing to find icons for .desktop files that use the Icon=domain.name format, while other parts of Xfce succeed.

#### Verifying Icon Name Consistency and File Presence

Before diving into more complex solutions, it’s essential to ensure that the icons themselves are correctly named and located within the hicolor theme.

  1. Identify the Exact Icon Files: Navigate to /usr/share/icons/hicolor/ and explore subdirectories like 16x16/apps/, 22x22/apps/, 24x24/apps/, 32x32/apps/, 48x48/apps/, 64x64/apps/, 96x96/apps/, 128x128/apps/, 256x256/apps/, and scalable/apps/. Look for files that are clearly the icons for dconf-editor, Evince, and Yelp.
  2. Check for Common Naming Conventions: The system typically looks for an icon named application-name. For GNOME applications, it’s common to see prefixes like org.gnome.Evince or org.xfce.Thunar. However, the hicolor theme often uses simpler names. For instance, dconf-editor might be represented as dconf-editor.png or dconf-editor.svg. Similarly, Evince might be evince.png or evince.svg, and Yelp might be yelp.png or yelp.svg.
  3. Cross-Reference with .desktop Files: Compare the names of the icon files you find with the Icon= entries in the .desktop files. The issue might stem from a mismatch in the expected icon name by Thunar versus the actual file name in the hicolor directory.

If you find that the Icon= entries in your .desktop files (e.g., Icon=org.gnome.Evince) do not directly correspond to the filenames found in /usr/share/icons/hicolor/ (e.g., evince.png), this could be a contributing factor.

#### Manually Creating Symlinks for Testing

A powerful diagnostic step is to create symbolic links (symlinks) that bridge the gap between the Icon= names in the .desktop files and the actual icon filenames. This will help us confirm if the naming convention is indeed the core of the problem.

  1. Navigate to the Icon Directory: Open a terminal and use cd /usr/share/icons/hicolor/scalable/apps/ (or a directory with the appropriate icon size).
  2. Create Symlinks: For each problematic .desktop file, create a symlink. For example, if the Icon= line is Icon=org.gnome.Evince and you find the actual icon file is named evince.svg, you would create a symlink:
    sudo ln -s evince.svg org.gnome.Evince.svg
    Replace evince.svg with the actual filename of the Evince icon. Repeat this for dconf-editor and yelp, ensuring you use the correct icon filenames. You might need to create symlinks for various sizes if a specific size is being prioritized by Thunar. A good starting point is the scalable directory if SVG icons are available, as they adapt to any resolution.
  3. Update Icon Cache Again: After creating the symlinks, re-run the icon cache update:
    sudo gtk-update-icon-cache -f /usr/share/icons/hicolor/
  4. Refresh Thunar: Close and reopen Thunar, or restart the Xfce session (log out and log back in) to see if the icons now appear correctly.

If creating these symlinks resolves the issue, it strongly indicates that Thunar was failing to resolve the Icon= names because they did not directly match the filenames expected by its icon lookup mechanism.

#### Modifying .desktop Files with Specific Icon Paths (Workaround)

While not our ideal solution, understanding this workaround is crucial for confirming the diagnosis and for immediate use if other methods prove elusive.

  1. Edit the .desktop Files: Open each of the three problematic .desktop files in /usr/share/applications/ with a text editor as root. For example:
    sudo nano /usr/share/applications/org.gnome.Evince.desktop
  2. Locate the Icon= Line: Find the line starting with Icon=.
  3. Specify the Full Path: Change the line to explicitly point to the icon file. For instance, change Icon=org.gnome.Evince to:
    Icon=/usr/share/icons/hicolor/256x256/apps/evince.png
    Again, replace evince.png and the specific directory (256x256/apps/) with the actual path to the correct icon file for Evince. Do this for all three applications.
  4. Save Changes and Update Icon Cache: Save the modified files and run the icon cache update command:
    sudo gtk-update-icon-cache -f /usr/share/icons/hicolor/
  5. Refresh Thunar: Restart Thunar or your Xfce session.

If this method successfully displays the icons, it confirms that Thunar was unable to resolve the icon name implicitly and required an explicit path.

#### Exploring Alternative Icon Theme Configurations

While you prefer to stick with the Tango theme, it’s worth understanding how other themes might handle such naming conventions. The hicolor theme acts as a fallback, and its structure and naming are usually based on Freedesktop.org standards.

The issue might be related to how Thunar or the underlying GTK libraries are configured to search within icon theme directories. The index.theme file within each icon theme directory (/usr/share/icons/Tango/, /usr/share/icons/hicolor/) defines the theme’s properties, including inheritance and directories to search. However, for hicolor, which is a base theme, this is less about specific naming rules and more about the structure of icon directories.

The problem may not be with the existence of the icon, but with the lookup mechanism of Thunar in this specific version of Xfce. It’s possible that the application menu system used by the Whisker Menu has a more robust or forgiving icon resolution process that can handle these specific Icon= formats without issue.

#### Checking for .desktop File Syntax and Placement Errors

Although unlikely given that the applications function correctly and appear in the Whisker menu, a brief check of the .desktop files themselves is always prudent.

  1. File Permissions: Ensure that the .desktop files in /usr/share/applications/ have read permissions for all users (chmod 644).
  2. Syntax Validity: While the applications are launching, a malformed Icon= line could cause resolution problems. However, the consistent use of Icon=domain.name across these three specific files suggests intentionality rather than a random syntax error.

#### Considering Thunar’s Internal Caching or Specific Logic

Thunar might employ its own internal caching mechanism for application shortcuts and their associated icons, which could be distinct from the system-wide icon cache updated by gtk-update-icon-cache. If this cache is not being invalidated correctly or if it’s specifically failing to process the Icon=domain.name entries, it would explain the discrepancy.

One method to try and force Thunar to re-read application configurations is to clear any Thunar-specific caches if they are known. However, without explicit documentation on such caches for Thunar versions of that era, this becomes more speculative. A full Xfce session restart is usually the most effective way to ensure all components are reloaded.

#### The Role of icon-naming-utils and Theme Inheritance

The icon-naming-utils package can sometimes play a role in mapping application names to icon names. While not typically installed by default on minimal Debian systems, it’s worth checking if it’s present or if its absence could be a factor. The hicolor theme itself inherits from other themes, and this inheritance chain can influence icon resolution. However, for system-critical icons provided by packages like dconf-editor, evince, and yelp, they are almost always placed in hicolor.

Hypothesizing the Root Cause: Icon Naming Conventions and Desktop Environment Interpretation

Based on our observations and troubleshooting steps, the most plausible explanation for the missing icons in Thunar, while they correctly appear in the Whisker menu, is a difference in how these two components interpret or prioritize icon resolution for .desktop files that use the Icon=domain.name format.

It is highly likely that the Whisker menu’s underlying system for populating application menus is more adept at translating these “reversed domain name” identifiers into actual icon filenames, possibly through a more extensive mapping database or a more forgiving lookup algorithm. This system might implicitly understand that org.gnome.Evince should be mapped to an icon named evince or similar.

Thunar, on the other hand, in this specific version (1.8.4 on Xfce 4.12), might be adhering more strictly to a direct filename lookup or a simpler convention for resolving Icon= entries. When it encounters Icon=org.gnome.Evince, it might be searching for an icon file literally named org.gnome.Evince.png (or .svg, etc.) in the icon theme directories, which doesn’t exist. It fails to perform the intermediate step of mapping org.gnome.Evince to evince.

The fact that other .desktop files with generic names like Icon=xfwm4 work correctly supports this. xfwm4 is a direct icon name that the system can easily locate within the theme’s structure.

The symlinking approach directly addresses this by creating the filename that Thunar appears to be expecting, effectively bypassing its restrictive lookup logic. Modifying the .desktop files with explicit paths achieves the same result by telling Thunar exactly where to find the icon, sidestepping the need for name resolution altogether.

Conclusion: Achieving Icon Consistency in Thunar

The issue of specific .desktop files failing to display icons in Thunar, despite functioning correctly in the Xfce Whisker Menu, primarily stems from how Thunar’s icon resolution mechanism interprets the Icon= key when it uses application identifiers in the domain.name format. While the underlying icon files are present and correctly named within the /usr/share/icons/hicolor/ directory, Thunar appears to require a more direct mapping or a different naming convention than what is provided by these specific .desktop entries.

We have explored several diagnostic steps and potential solutions. The most effective methods to resolve this issue involve either:

  1. Creating symbolic links within the icon directories that map the Icon=domain.name entries to the actual icon filenames. This is a robust solution that ensures the system can find the icons as Thunar expects them, without altering the original .desktop files.
  2. Explicitly specifying the full path to the icon file within the .desktop files themselves. While this is a workaround, it directly addresses Thunar’s need for a precise location, guaranteeing icon display.

We recommend attempting the symbolic link approach first, as it is generally a cleaner method that doesn’t involve modifying system-provided application metadata. By ensuring that an icon file is accessible via a name that Thunar can directly resolve, we can restore the visual consistency of your application launcher. The consistency of icon display is not merely an aesthetic preference; it contributes to a more intuitive and efficient user experience. At revWhiteShadow, we are dedicated to helping you achieve this level of polish on your Debian Buster Xfce system.