Description: We have a spec used in GNOME and KDE Plasma, so file/open dialog, recent files in menus and file managers reflect the files opened in apps: https://specifications.freedesktop.org/recent-file-spec/recent-file-spec-0.2.html This would prevent the need to watch ".config/libreoffice/4/user/registrymodifications.xcu" to get this information and allow spec compliant DE to surface more directly. As in: https://invent.kde.org/plasma/kactivitymanagerd/-/merge_requests/57 Gtk has an API for this https://docs.gtk.org/gtk3/class.RecentManager.html Steps to Reproduce: 1. in libreoffice open a document from the recently used document list Actual Results: ~/.local/share/recently-used.xbel is not updated for the file entry. Expected Results: See the entry for the file in ~/.local/share/recently-used.xbel updated. Reproducible: Always User Profile Reset: No Additional Info: Update ~/.local/share/recently-used.xbel as files are opened in libreoffice.
I've noted a different behavior. Saved docs (.docx in my case) are added to gtk recent files. But when you save as pdf, the file is stored without ".pdf" extension and so the link refers to non existent file and won't be shown in recent directory.
(In reply to wisedevman@gmail.com from comment #1) > I've noted a different behavior. > Saved docs (.docx in my case) are added to gtk recent files. > But when you save as pdf, the file is stored without ".pdf" extension and so > the link refers to non existent file and won't be shown in recent directory. This seems to me like an issue for the implementation of the file saver, GNOME here it seems, are a code issue in how libreoffice uses the file opener API. This bug is focused on the "reopening a recent file from within libreoffice", not about open or save use case.