Long time ago GNOME Files (Nautilus) had the ability to handle custom annotations attached to files and directories. This ability has slowly gone lost in the folds of time. Things however are rarely really unlearned, and an ability rarely goes away for good.
Nautilus Annotations brings back Nautilus’ annotation capabilities. It exploits the same machinery that was used back then: that of relying on GIO to store custom information about a file or a directory.
Each annotation is stored as a metadata::annotation entry in GIO’s database. Annotated files are shown in the viewport with an emblem attached.
To erase an annotation it is sufficient to leave the content blank, and the extension will take care of erasing the database entry.
The dialog window for editing the annotations is very minimal, albeit polished and with Markdown highlighting enabled.
Thanks to GIO, when a file is moved or renamed its annotations remain synchronized with the new path.
Annotations are “per user”. That means that although Alice has the right to annotate Bob’s files, only Alice will have access to her own annotations.
Emblems are managed by the extension and will not be shown once the extension is uninstalled. The content of the annotations instead is managed by GIO and will survive uninstalling the extension.
It is possible to access annotations via command line by launching:
sh gio info --attributes='metadata::annotation' /path/to/file
For setting an annotation via command line launch instead:
sh gio set /path/to/file 'metadata::annotation' 'Content of annotation goes here'
For giving it a try, you can compile and install the package from source; or if you use Arch Linux, download directly the PKGBUILD attached to the last release.
The project is still very young and needs help with internationalization. If you like the idea and your first language is not English, then you can help. I will also appreciate any constructive feedback.
Thank you for your comment, António. This was not my first Nautilus extension, I had written three extensions before, although they are smaller projects (see Nautilus Bluetooth, Nautilus Hide and Nautilus Launch). I had even written a small shell script for setting up a new Nautilus extension project from scratch easily (see NExtGen).
I love the fact that Nautilus has an extensions API at all! The things I would improve are the documentation (there are many undocumented functions, and although their name might be an obvious hint about what they do I believe that everything should be documented, especially because there can always be edge cases and useful examples to give). And in general I would give extensions a bit more power.
For example, if I want to add a GtkAccelGroup to every Nautilus GtkWindow, how should I do? I have access to the GtkWindow object from some of the API’s callback functions, but they seem all the wrong places for setting up a GtkAccelGroup. The right place would be a callback function that triggers when a Nautilus window is generated. But no callback function is invoked in that moment.
Or, for example, my Nautilus Hide extension updates the .hidden files that are present in folders, but Nautilus is slow at acknowledging the changes and one has to press Ctrl + H twice to see them applied – and I believe that nautilus_file_info_invalidate_extension_info() would not work in this case, becase what Nautilus is slow at is updating the information it holds from the .hidden file; my extension would probably need a nautilus_hidden_database_invalidate_extension_info(), which does not exist.
So basically I want more power for extensions!
But I really love the whole idea behind the Nautilus extension API.
I am thrilled by the idea! Especially if porting Files to GTK4 will give extensions more public functions/objects to play with!
After playing a bit with the Extensions API I can collect a bit of thoughts. My first thought is that the Extension API is in general well designed and consistent, so it should be taken care of. Places where I would intervene are:
Add a tab in Nautilus preferences for enabling/disabling extensions (and possibly give the latter a “settings” option, for extension-specific settings)
Document every single public object and function in the manual (it cannot remain as it is now) – for example, what is nautilus_file_info_add_string_attribute()? What kind of attribute does it add? Is it a GIO attribute? A Nautilus-scoped one? Etc. etc.
Give extensions access to popup notifications (that semi-transparent pop-up message that appears when Nautilus has completed a file transfer)
I am not sure if this is already possible, but it seems to me that it is not: give extensions the possibility of creating a custom “fake” folder from scratch (like the “Favorites” fake folder for instance). This would allow to do amazing things, like navigating through the history of a git repository as if Nautilus was a time machine, or creating a GNUnet folder, and many many more possibilities.
Give extensions access to Nautilus’ cached .hidden file (for refreshing it when necessary)
Give extensions a facility for creating keyboard shortcuts (maybe implementing a NautilusAccelGroupProvider interface?); shortcuts should have access to the current window widget and the current file selection GList; shortcuts are not guaranteed and may be silently refused by Nautilus (maybe throwing a kind message to stderr).
Maybe not all my thoughts will be agreed with, but I am confident that at least some will be.
In the meantime I have finished polishing my Annotations extension and I think I might leave as it is now for a while. Have you tried the latest version? Do you have any feedback about it?
