Bug 107755 - store recently opened files list only in recently-used.xbel instead of registrymodifications.xcu too
Summary: store recently opened files list only in recently-used.xbel instead of regist...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-10 15:51 UTC by Hussam Al-Tayeb
Modified: 2018-03-09 05:56 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hussam Al-Tayeb 2017-05-10 15:51:46 UTC
Most Linux applications store recently opened files in ~/.local/share/recently-used.xbel and just read that file and filter it in open dialogs.

Libreoffice stores this list in its own configuration directory inside the registrymodifications.xcu file as well. It shouldn't do that. It should only look at recently-used.xbel and filter it for supported files then show those in the start screen.
Note that the gtk+ open dialog is indirectly storing the entries from opened files using libreoffice anyway in recently-used.xbel.
Comment 1 Jean-Baptiste Faure 2017-08-07 09:51:34 UTC
LibreOffice is not a Linux only software. What do you propose to manage recently used files from a cross-platform point of view ?

Set status to NEEDINFO, please set it back to UNCONFIRMED once requested
informations are provided.

Best regards. JBF
Comment 2 QA Administrators 2018-03-02 10:01:28 UTC Comment hidden (obsolete)
Comment 3 Hussam Al-Tayeb 2018-03-02 15:33:40 UTC
(In reply to Jean-Baptiste Faure from comment #1)
> LibreOffice is not a Linux only software. What do you propose to manage
> recently used files from a cross-platform point of view ?
> 
> Set status to NEEDINFO, please set it back to UNCONFIRMED once requested
> informations are provided.
> 
> Best regards. JBF

maybe #ifdef __linux use recently-used.xbl
#else the platform independent format>
Comment 4 Jean-Baptiste Faure 2018-03-02 21:04:25 UTC
The list of recent files provided by my Nautilus (Ubuntu 16.04) is clearly wrong from a LibreOffice point of view because it shows ODF files accessed during the last hour that I did not open since several weeks. So your proposition seems not be able to provide better information than the current recently used files implementation.

Best regards. JBF
Comment 5 Hussam Al-Tayeb 2018-03-02 21:13:54 UTC
what does
"gio info /path/to/your/file.odt | grep time" say? (assuming the file name is file.odt)
Comment 6 Jean-Baptiste Faure 2018-03-02 21:34:20 UTC
(In reply to Hussam Al-Tayeb from comment #5)
> what does
> "gio info /path/to/your/file.odt | grep time" say? (assuming the file name
> is file.odt)

no gio command. Which package is missing?

Best regards. JBF
Comment 7 Hussam Al-Tayeb 2018-03-02 21:59:08 UTC
It should be part of glib2. Glib2 may be called something else on your distribution.
An alternative is to run gvfs-info /path/to/file.

I may have some clues as to why the modified date is incorrect on your installation. Would you mind keeping this bug open in case someone is able to spare time to take a look? At least correctly populating the Recents panel in gtk+ file dialog will be a welcome enhancement as it prunes stale entries.
Thank you.
Comment 8 Jean-Baptiste Faure 2018-03-04 16:49:20 UTC
(In reply to Hussam Al-Tayeb from comment #7)
> It should be part of glib2. Glib2 may be called something else on your
> distribution.
> An alternative is to run gvfs-info /path/to/file.
> 
> I may have some clues as to why the modified date is incorrect on your
> installation.

The modified date is also wrong for non-ODF files like archives, PDF files or MS-Windows executables. Perhaps because my home is encrypted, but that is not a good reason to return false data.

Best regards. JBF
Comment 9 Hussam Al-Tayeb 2018-03-04 16:55:43 UTC
Can you please post the result of:
gvfs-info /path/to/a/file.pdf | grep time
and
ls -l /path/to/a/file.pdf?
Comment 10 Jean-Baptiste Faure 2018-03-08 22:23:49 UTC
Another argument against your proposition is that recently used does not mean the same thing at LibreOffice level and at OS level. At LibreOffice level it means this file has been opened by LibreOffice. At OS level it means this file has been read or open by some program. There is a lot of other softwares than LibreOffice that can change the last modified date of an office file. In other words the recently used files list of LibreOffice gives a more precise and useful information than the one from the OS.

So closing as WontFix.

Best regards. JBF
Comment 11 Hussam Al-Tayeb 2018-03-08 22:42:58 UTC
(In reply to Jean-Baptiste Faure from comment #10)
> Another argument against your proposition is that recently used does not
> mean the same thing at LibreOffice level and at OS level. At LibreOffice
> level it means this file has been opened by LibreOffice. At OS level it
> means this file has been read or open by some program. There is a lot of
> other softwares than LibreOffice that can change the last modified date of
> an office file. In other words the recently used files list of LibreOffice
> gives a more precise and useful information than the one from the OS.
> 
> So closing as WontFix.
> 
> Best regards. JBF

If I try to open a non-existent file using a native gtk+ application, it automatically prunes the non-existent file from the recent files file. Both KDE and Gnome benefit from this.
LibreOffice simply clutters its recent files storage and doesn't clean up after itself by removing stale entries on failure to open them which also poses a privacy issue because users of FDo compliant desktops (Gnome/KDE/etc...) are expecting the opposite different behavior.
Do you understand what I was after here and my concern?

It's your software so you can go ahead and not fix it if you wish but it is really not Ok at all to ignore privacy issues.
Comment 12 Jean-Baptiste Faure 2018-03-09 05:56:05 UTC
(In reply to Hussam Al-Tayeb from comment #11)
[...]
> LibreOffice simply clutters its recent files storage and doesn't clean up
> after itself by removing stale entries on failure to open them [...]

This problem is already tracked by this bug report : https://bugs.documentfoundation.org/show_bug.cgi?id=101302

Best regards. JBF