Skip to content

Draft: Ability to set custom icons for files and folders

Arash Rohani requested to merge arash-rohani/thunar:custom-icon into master

Give users the ability to set custom icons for files and folders.

Users can click the icon on the file's properties dialog and select an icon name or path just like .desktop files.

If thunar is run with gvfs, it tries to get/set "metadata::icon". If thunar is run without gvfs, it tries to get/set "xattr::icon" which is equal to "user.icon" xattr in other programs (e.g. setfattr).

Users can also use the command line equivalent of properties dialog option:

# for gvfs
dbus-launch gio set <file> 'metadata::icon' <absolute_path_or_name_of_icon>

# for xattr
gio set <file> 'xattr::icon' <absolute_path_or_name_of_icon>
# or
setfattr -n user.icon -v <absolute_path_or_name_of_icon> <file>

A few things need to be tested before merging this:

  • Without gvfs present, try setting the icon xattr from the dialog on operating systems that don't support xattrs.
  • Without gvfs present, try setting the icon xattr from the dialog on ext4/btrfs system with small (e.g. 512B) block size. Set icon as an absolute path which exceeds the small block size limit and see if xattr will throw an appropriate error or will it just set the incomplete path as the value and the icon gets broken.
  • Does it have any noticeable slow downs on folders with loads of files? Every non-desktop file first checks if gvfs is present to find the correct attribute and set the icon. Also the icons need to be rendered.
  • In order to show the icon change immediately I had to use thunar_file_reload () instead of thunar_file_changed (). Will that cause some weird issues later?

A few questions:

  • Right now whenever we need to use gvfs metadata (all over the repo), we check the availability with thunar_g_vfs_metadata_is_supported () right before the action. Can we just check gvfs metadata support once when the application starts and not do it for each file/operation? Is it common (or even possible) for this check to suddenly flip mid application run?
  • Should there be a similar check for xattr support before trying to get/set it? When I wrote this I didn't know we can get/set extended attributes with gio and thought the compatibility will be a nightmare. But if gio can handle the errors and incompatibility gracefully we can do this for other metadata as well.
  • Should exo#5 be fixed first before merging this? If we don't then users will immediately encounter it when using certain icon themes. For example Papirus folder icons are all symlinks to the currently selected color and won't show up in the icon chooser options. Of course command line can always be used in these situations but that is not ideal.
  • When gvfs is enabled, isn't it better to show untrusted desktop icons/names anyway and use an emblem to communicate the untrusted nature of the file? Right now setting the icon of the .desktop file can be confusing (and seem buggy) if the user is unaware of the reason.
  • Isn't it better to keep the properties dialog icon clickable at all times and let the user encounter the error when they try to change it? IMO the current behavior is more confusing to users.

Merge request reports