Feature request: Nautilus file comments

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.

The following link was referenced: https://www.freedesktop.org/wiki/CommonExtendedAttributes/

There it says:

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 :speech_balloon: 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?

1 Like

As a POC, here’s a shell script which uses this attribute name to get/set a comment on a file: https://gist.github.com/yawaramin/0f15292b605a96b24943bf09dade1fa8

1 Like

Hi @yawaramin!

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.

What would be your use-case for such comments?

1 Like

Thanks for the idea!

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).

Hi @p3732 and @antoniof, thanks both for your feedback. I’ll try to answer the questions here.

Use-cases for file comments:

  • As a Nautilus user, I want to comment on a file to track information like where I got it from, or how I created the file, etc.
  • As a user, I want to comment on a directory to provide more details about what’s inside it.

On macOS, when you bring up a file properties window:

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: https://github.com/Dijji/FileMeta/wiki/What-you-see

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 :speech_balloon: 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.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.