This might seem like a silly idea to you, but I think it makes a lot of sense, let me explain.
Currently, users can assign a custom icon to any file using gio with a simple gio set -t string myfile.txt metadata::custom-icon file:///path/to/icon.svg. The downside to this is that, at the system level, it is difficult for a programmer to set up custom icons for, say, a custom pseudo-file system that uses FUSE. However, there is something that can be done.
My suggestion is that, just as Nautilus (or gvfs, I’m not actually sure which one it depends on) can read the gio custom icon property, it should also be able to read it from xattr (for example, from user.custom-icon or user.metadata.custom-icon). This way, a programmer could set the icon simply by setting that extended attribute.
I find this particularly useful for what I was telling you about FUSE earlier. As a programmer, I can design the file system representation to include those extended attributes, so that when the user mounts my FUSE pseudo-system, the corresponding icons will appear.
The request is reasonable from a developer-experience perspective, especially for FUSE-based virtual filesystems that want self-contained metadata. However, it conflicts with GNOME’s portability model. Relying on xattrs would introduce backend inconsistencies, filesystem capability checks, and unclear fallback behavior.
That statement doesn’t make much sense in the context of what I’m proposing, since if I’m building the file system with FUSE, I’ll make sure it supports xattr.
The problem with using GVFS is that it isn’t as widely supported as FUSE. FUSE works everywhere, while GVFS only works in GNOME.
On the other hand, I’m not entirely sure if the goal I’m proposing could be achieved using only GVFS (that’s just a lack of knowledge on my part; I’d have to look into it).
I don’t quite understand what the problem would be. I’m not talking about relying entirely on xattr far from it, but rather that the system be able to check them with minimal or no priority and, if they exist, retrieve the value and display the icon in the same way it currently does with GIO. I don’t see how that would change the fallback behavior in any way.
One point I wanted to mention is that at some point we’ll have to tackle the xattr issue head-on. It’s not something we can ignore forever, since, in my opinion, it’s the most standard way to handle extended attributes, ensuring they’re 100% portable, and thus preventing each desktop environment from becoming an isolated island.
Perhaps the way to achieve this is to somehow translate these attributes to GVFS, but of course, I don’t think ignoring the issue is the most sensible course of action in the long run.