Hi, if this isn’t the appropriate place to discuss this, happy to move elsewhere. From a previous conversation:
raw xattrs aren’t meant to be exposed in the UI directly like that. Instead, apps should process the xattrs they understand and use them to power UI features.
Extended attributes are especially useful when they add information that is not present in the in the actual file. Depending on the file origin, an application can add metadata that is not present and/or can not be specified by the file or its format. For example file downloaded from a web server can be tagged with the url, which can be convenient if its source has to be determined in the future.
…
These attributes are currently proposed
user.xdg.comment: A comment specified by the user. This comment could be displayed by file managers
…
My feature request, or perhaps question to the GNOME (Nautilus) developers, is: is there any appetite for using the user.xdg.comment attribute to implement a ‘Comment’ UI in the file properties dialog? It could be a new ‘Comment’ tab, or even a ‘Comment’ text area in the ‘Basic’ tab. Would be super useful for people to keep notes on files.
If we want to get fancy: we could even show a next to the filename for files with a non-empty comment.
I understand that Nautilus used to have some custom ‘notes’ feature which was removed, but perhaps it can be considered again using an XDG proposed standard to back it up?
I think for something like this to be considered, it would need a pretty good use-case. Since the feature was removed, I suppose that there were none that were convincing enough (or the implementation complexity was too high compared to its usefulness). A proposed XDG standard does not really help with that.
In addition to use cases (with example scenarios for real life tasks that are in need for a solution/better experience), it would be interesting to see relevant art (how other apps/systems present and handle file comments).
On Windows, the ‘comments’ field does not exist for all files uniformly, but the ‘FileMeta’ Windows Explorer extension adds one. Detailed screenshots are available here: What you see · Dijji/FileMeta Wiki · GitHub
One caveat that needs to be taken into account–xattrs are not completely integrated out of the box into Linux userland utilities/applications. For example, the cp utility has a --preserve=xattr flag, which copies xattrs when copying files. This is not the default however. Similarly for the rsync --xattrs flag. And of course xattrs could not be preserved at all when transferring files across different systems.
If Nautilus were to implement file comments, we would need to ensure that xattrs were preserved by its ‘copy file’ API, so that at least for users staying within the GNOME system, file comments would work correctly.
Windows does have System.Comment for file comments - can’t say I know where it’s exposed in UI (if at all). At one point Windows used alternative streams for metadata type stuff.
If we were to do this a gio/gvfs property seems appropriate, though of course very fragile
Let’s not waste time discussing technical details in advance. Design goals and non-goals come first. If file comments are deemed worth having by default, we can decide which technical solution fits the goals. xattrs is just one option. Other options include gvfs-metadata (already used for custom icons), Tracker database (already used for starred files), or even a hidden file .comments in the directory (ugly, but portable).
True. To me xattrs have a slight advantage because they’re a two-decade-old Linux technology, but I’m not terribly attached to them. In terms of design goals, the ‘minimum viable product’ would be:
The comment should be stored somewhere reliably
The comment should be preserved when the file is copied or moved in Nautilus
Nice-to-haves:
Comments are indexed in GNOME’s Search feature, under Files
Nautilus renders files with comments with some icon in the file view, something like perhaps
Non-goals:
Preserving comments when the file is copied or synced using any non-GNOME tool
Preserving file comments across different systems, i.e. any kind of network transfer
The last non-goal is, to me, actually a rather nice benefit; file comments on my GNOME system are guaranteed to remain private in my system, and won’t be exposed when sending the file anywhere.
The second use case is well covered by having a “README” text file or something like that in the directory.
The first one is trickier to do without file comments. On the other hand, you’d probably not want to lose such metadata, which is a risk if comments are not portable.
I’d say yes–for technical users. We would think of putting a README file in the directory. But then again, even among technical users there’s no universal agreement on that. For example, many git repositories use a .gitkeep file to keep an empty directory in version control, while others recommend using a README file in the directory to explain what it is.
I think it would be good to treat files and directories in a uniform way when it comes to comments. Would probably make the implementation simpler too–we wouldn’t need to special-case directories.
Yes, this is the main problem with file comments–no guaranteed way to preserve the comments, no matter what storage method you use. I hear the KDE folks have been struggling with this for a long time. But think about it this way–even on macOS, file comments are not preserved by a simple cp operation. Nothing’s perfect, but it still works and is a useful feature in a lot of cases.
next to the filename for files with a non-empty comment.