Freedesktop "Recent File Storage Specification" broken by concept - what's the correct way to fix it?

Stefan Blachmann sblachmann at
Thu Sep 3 13:47:36 UTC 2020


All DMs and OSes (Windows, MacOS) provide a menu for recently used files.
The freedesktop "Recent File Storage Specification" was probably
intended as an unified means to provide freedesktop software users
with access to recently used files via a start menu.
The specification is here:

However, the concept is broken from the beginning.
The factual inclusion of the browsing history renders it useless.

Actual recent documents get shoved out of the list by broswing trash in no time.
The lists' small size (~70 entries) in actual distributions aggravates
the problem a lot.
So the well-intended concept in practice degenerates into a redundant
browser history, which nobody needs.

For this reason neither KDE nor Gnome appear to make use of that
broken-by-concept Freedesktop "Recent File Storage Specification" to
generate their "Recent" menus.
Instead they use their proprietary solutions.

So the concept should be corrected to be actually practical.
Definitely clear is that the browsers' history data belongs into
another file, say, ~/.RecentlyVisitedURLs.

Why am I posting this?
I am working on a start menu script for FVWM.
I need to find a temporary solution to fix the problem, until the
specification got corrected and browser makers updated their software

Do you think that a cron script that regularly filters
"~/.recently-used" would be appropriate?
Its task would be to separate the data in "~/.recently-used" into two files:

-the actually user-generated or locally-stored documents that have
been accessed or worked on by non-browser software. This "List of
Files Recently Used by Me" then could keep the files that were moved
out of the "~/.recently-used" file by web history trash and provide
the user with an actually usable recently-used-files list.
-the web page history which the start menu then can combine with a
convenient "Open With Browser..." option.

Do you know less-awkward solutions to the problem?

I'd be really grateful about a discussion how to fix the specification.

Thank you,

More information about the xdg mailing list