TL;DR: I built a POC that adds a toggle button to Nautilus for folders like Downloads and Screenshots. When activated, it overrides the view mode to list view and adds date-based section headers (“Today”, “Yesterday”, “Previous 7 Days”, etc.). The code is rough and the UX needs refinement. I’m posting to gauge interest before investing more effort.
The problem
Currently Nautilus applies the view mode (grid/list) globally, while sort settings are per-folder. For most folders this works fine. But for folders like Downloads, Screenshots, and Screencasts, the global view mode gets in the way.
For example: I prefer grid view sorted by name for most folders, and that makes sense almost everywhere. But the Downloads folder is always annoying. A grid sorted by name is not very useful there, so I end up switching the view mode every time I open it, then switching back when I leave. Or I just settle with a view I don’t like.
You can already set Downloads to sort by date modified and that sticks. But the grid view itself isn’t great for browsing chronological content, and even in list view there’s no visual grouping to help you orient in time. You just see a flat list.
This was discussed previously in Nautilus: per-folder view settings
What Smart View does
Smart View takes a narrower, more opinionated approach than general per-folder settings:
-
A toggle button appears in the toolbar only when you’re in an eligible folder (currently:
~/Downloads,~/Pictures/Screenshots,~/Videos/Screencasts) -
When activated, it overrides the view mode to list view, sets sort to date modified (newest first), and adds date-based section headers: “Today”, “Yesterday”, “Previous 7 Days”, “Previous 30 Days”, then monthly groups (“January 2025”, “December 2024”, …)
-
The toggle state is remembered per-path for the session, so navigating away and coming back keeps it on
-
Switching view mode manually (e.g. clicking the grid/list toggle) deactivates Smart View
What I think works well
After using this for a while on my own machine:
-
Finding recent downloads is much easier. The “Today” / “Yesterday” sections immediately orient you in time, which a flat sorted list doesn’t do.
-
It’s opinionated in a good way. You don’t configure anything, it just works for the folders where it makes sense. I think this aligns with GNOME’s design principles of having a simple, well-considered default rather than exposing knobs.
-
The escape hatch is natural. If you don’t want it, just click the regular view toggle or the Smart View button again.
-
Screencasts and Screenshots benefit equally. These are folders you visit specifically to find “that thing I just recorded/captured.”
Prior art: how other file managers handle this
This isn’t a new idea. Several major file managers already offer date-based grouping, with different approaches:
Windows 11 File Explorer is the closest precedent. It automatically enables “Group by: Date modified” in the Downloads folder by default, and it’s the only folder where it does so. Section labels use relative terms: “Today”, “Yesterday”, “Earlier this week”, “Last week”, “Last month”, “Earlier this year”, “A long time ago”. The setting is per-folder. Worth noting: this has been polarizing, many users search for ways to disable it.
macOS Finder supports grouping via View > Use Groups > Group By Date, with labels: “Today”, “Yesterday”, “Previous 7 Days”, “Previous 30 Days”, then month names and years. It is not automatic for Downloads though, users must enable it manually. The Downloads folder does default to sorting by “Date Added”, but without section headers. The setting is per-folder and persistent. Desktop Stacks use the same date buckets.
KDE Dolphin supports grouping via View > Show in Groups (Ctrl+G) when sorted by a date field. It has the most granular labels: “Today”, “Yesterday”, individual weekday names, “One Week Ago”, “Two Weeks Ago”, “Three Weeks Ago”, “Earlier this Month”, then “Month, Year”. Not automatic for any folder, purely user-triggered. Per-folder when “Remember display style for each folder” is enabled.
iOS Files supports Group By Date with the same label scheme as macOS Finder. Not automatic for Downloads.
Nemo (Cinnamon), Thunar (XFCE): Neither supports date grouping with section headers at all.
Android file managers (Files by Google, Samsung My Files) don’t offer section-header grouping either. They provide category-based browsing or flat sorted lists.
Summary
| Auto for Downloads | Date grouping exists | Per-folder | |
|---|---|---|---|
| Windows 11 | Yes | Yes | Yes |
| macOS Finder | No (sort only) | Yes | Yes |
| KDE Dolphin | No | Yes | Yes |
| Nemo / Thunar | No | No | N/A |
| iOS Files | No | Yes | Yes |
A few things stand out:
-
Windows 11 is the only major platform that auto-enables this for Downloads, and it’s controversial but clearly addresses a real need
-
macOS and KDE both offer the capability but leave it manual, which means most users never discover it
-
The label schemes differ (macOS uses fixed day ranges, Windows uses relative week/month terms, KDE is most granular with weekday names). My current implementation follows the macOS pattern
-
Every implementation that supports grouping does it per-folder, not globally
The Smart View approach tries to split the difference: opinionated like Windows’s approach but opt-in like macOS (a toggle, not forced).
Concerns and open questions
UX complexity:
-
Adding another button to the toolbar (even conditionally visible) increases cognitive load. Is this the right surface for it, or should it be in a menu?
-
Users may be confused about why the button appears in some folders but not others.
Scope creep risk:
-
If we limit to specific XDG dirs, people will ask “why not my Projects folder?” If we open it to all folders, it becomes the per-folder settings feature that was intentionally removed.
-
The current allowlist (
~/Downloads,~/Pictures/Screenshots,~/Videos/Screencasts) is hardcoded. Should this be configurable? Or should it stay opinionated? -
An alternative would be to make the toggle available everywhere, but I think that would be equally confusing. A date-grouped view makes no sense in most folders (e.g. a project source tree,
/usr/share, a folder of manually curated photos). Showing the button everywhere would invite users to enable it in contexts where it actively makes things worse, and then they’d blame the feature. The narrow allowlist is a deliberate tradeoff: it limits the feature’s reach but ensures it only appears where it genuinely helps.
Section headers depend on list view:
GtkGridViewdoesn’t support section headers yet (GTK MR !6002). Until that lands, Smart View forces list view, which may surprise grid-view users.
Code complexity:
-
The state management for activating/deactivating across navigation, view switches, and loading callbacks is non-trivial. The
view_ended_loading()override exists specifically to work around crash scenarios. -
The sort override has to be carefully bypassed so it doesn’t get saved to the folder’s metadata. Otherwise deactivating Smart View would leave the folder with sort settings the user didn’t explicitly choose.
Current status
This is a proof of concept. The code is not ready for review, it needs cleanup, proper error handling, and the UX needs significant design input. I’m sharing it to understand:
-
Is this a direction Nautilus wants to go? The narrow, opinionated approach (vs. general per-folder settings) is intentional, does it make sense?
-
Are the target folders right? Downloads + Screenshots + Screencasts cover the main chronological use cases I can think of. Are there others?
-
Is a toolbar toggle the right interaction? Or would something like an automatic mode (always on for these folders, with a way to disable) be better?
The branch is smart-view if anyone wants to try it out.
Would love to hear thoughts from designers and maintainers on whether this problem space is worth pursuing, and if so, what the right approach looks like.
.