Hi there, GNOME Planet.
In my last post I’ve promised that the next one would have screenshots of new developments in the Files app, and it’s finally here!
It took me longer than I expected back then. After the 3.38 release, I had to focus my time elsewhere: assisting and training local primary health care teams in managing and following up of the raising number of COVID-19 cases assigned to them. With this mission accomplished, in December I’ve picked up again on my GNOME contributions and have something to show you now.
Files 40.alpha
Last week we have reached the alpha milestone for the upcoming version 40 of GNOME Files. The highlights of this pre-release milestone are a long requested feature to show files creation timestamps and an enhancement to the Set as Wallpaper action.
Creation date
Finally the screenshots!
This was made possible thanks to Thunar developer Andre Miranda’s laudable initiative to implement the low-level glue for all GIO-based apps to benefit from. It was then easy for me to add the column to list view, and for Apoorv Sachan to add it to the Properties dialog (a nice follow-up to his GSOC project cleaning up the Properties code and UI).
This is a new feature, so it would be great to have people testing it before the final release. It’s easy to test, see instructions at the end of this post.
There as some open questions:
- What to do for files and folders in file systems for which we don’t have access to the creation date (e.g. FAT, NTFS)?
- Should we do something in case the Modified date is older than Created date, which is counter-intuitive even if technically correct?
Wallpaper Portal
There is a “Set as Wallpaper” action in the context menu for image files, which had a few odd behaviors which were not in sync with the user experience provided by the Settings app.
Thanks to Felipe Borges, not only have these problems been fixed, but the feature has been enhanced! Now you get a preview of the wallpaper, so you can confirm this was the correct picture and whether it’s going to look good, before confirming the desktop wallpaper change.
This is provided by the wallpaper portal created for sandboxed apps, but it works even outside Flatpak.
More coming soon
There are some more enhancements which didn’t make it into this milestone, but which I hope to be able to deliver before the beta milestone. I’ll talk about them in a future post.
I’m also very happy to see many new contributors fixing both major and minor bugs and implementing exciting features in the Files app. Now, back to reviewing the MRs, so that I can highlight their contributions in a future post!
Testing
For testing the latest developments in GNOME Files, without modifying the Files app in your system, there is a Nightly flatpak. To install it, copy and run the following command in a Terminal:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
The Nightly can now be launched from Activities, or with this command:
flatpak run org.gnome.NautilusDevel
(If your operating system doesn’t support flatpak out of the box, see the Quick Setup guide.)
Nice to see improvements like this to roll in 😀 Thanks!
It’s good to know! Stay tuned for more to come. ?
Very nice!
> What to do for files and folders in file systems for which we don’t have access to the creation date (e.g. FAT, NTFS)?
Both track creation dates, so this sounds like a bug with the driver not exposing them via statx(), not a GNOME issue.
(Same for zfs, unfortunately its github issue for statx has stalled…)
I would still display the field, but show “Unknown” as the value.
> Should we do something in case the Modified date is older than Created date, which is counter-intuitive even if technically correct?
Maybe show Modified as “Contents modified” as the first item, and Created/Accessed as “File created/accessed” below it? This might make it clearer that Modified is a different kind of date.
> Both track creation dates, so this sounds like a bug with the driver not exposing them via statx(),
Correct. FAT calls creation date “cdate”, which in Linux has a different meaning, so the driver got them mixed. And the ntfs-3g driver depends on FUSE, which doesn’t support statx yet. https://gitlab.gnome.org/GNOME/nautilus/-/issues/1734#note_1002675
Thanks for both suggestions!
Thanks for pointing out the stalled GitHub tickets around ZFS support ¹ ².
Let’s see if we can raise awareness in the issue and PR to the widespread release of GNOME 40 via Fedora and Ubuntu this year ³.
¹ https://github.com/openzfs/zfs/issues/8507
² https://github.com/openzfs/zfs/pull/8509
³ https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-21.04-GNOME-3.38
Will files be ported to gtk4 for this next release?
For version 40 I don’t think so. Maybe 41.
Where do you get the creation time? With what filesystems does it work? Because on classical Linux filesystems like ext4, there is no such thing as the creation time for files I thought. (Note that “ctime” is not “creation time” but change time of the metadata)
ext4 itself has always supported creation time, but it was only recently that Linux got support for reading it.
Great progress!
As requested, I’ve tried the nightly flatpak release and found it to integrate well with this F33 system on btrfs.
A little glitch are the UI strings that weren’t translated yet.
Should that be reported in https://gitlab.gnome.org/GNOME/nautilus/-/issues next to
* https://gitlab.gnome.org/GNOME/nautilus/-/issues/1566
* https://gitlab.gnome.org/GNOME/glib/-/issues/1970
instead?
Or would that rather be picked up by the https://l10n.gnome.org/module/nautilus/ translation communities, and/or can be contributed there?
Yes this is handled by translation teams.