SUMMARY The "recent files" item in the save/open KDE dialogue shows only a partial view of recent files. STEPS TO REPRODUCE 1. save one or more files in GIMP 2. in Firefox, click on an upload button so the open/save dialogue opens 3. select the "recent files" item in the menu on the left OBSERVED RESULT The files you recently saved are not there. They sometimes are, however, present in the "today" item. EXPECTED RESULT All recent files are listed in the "recent files" dialogue SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon KDE Plasma Version: 5.19.3 KDE Frameworks Version: 5.72.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION
Can you confirm that the URL of your "Recent Files" item is "recentlyused:/files"?
(In reply to Nate Graham from comment #1) > Can you confirm that the URL of your "Recent Files" item is > "recentlyused:/files"? Yes. I just verified that the problem appears different from what I thought it to be, as there seems to be a random delay in when the files are added to the list. I just saved a file and saw that it was immediately presented in the "recent files", but it took a couple of minutes for them to appear in "today". So what I have witnessed so far, in terms of stuff not appearing in "recent files", now appears to be a coincidence rather than an issue specific to that menu item; it seems to be just a manifestation of a problem in how the recent files are managed/shown according to my latest findings.
Forget about "Today" and those others. Those are the old Baloo-based items that never quite worked right because they perform filesystem scanning, so newly created items may take a while to show up there, making it useless for this use case. IMO we should just remove them from the Places panel by default (if we haven't already, I can't remember). `recentlyused:/files` is a newer, better, notification-based system that relies on other apps to tell it to add items to the list, which makes them show up instantly, but relies on apps playing nice and adding their items to the list. KDE software will do this, but GNOME apps will not, which is why files saved by GIMP don't instantly appear. GNOME apps use a different, cross-desktop API which frankly we should be using too. However I had thought that we were working around this by introspecting the file that backs the cross-desktop thing that GNOME uses. Méven, do you remember the details? It's getting hazy for me.
(In reply to Nate Graham from comment #3) > Forget about "Today" and those others. Those are the old Baloo-based items > that never quite worked right because they perform filesystem scanning, so > newly created items may take a while to show up there, making it useless for > this use case. IMO we should just remove them from the Places panel by > default (if we haven't already, I can't remember). > > `recentlyused:/files` is a newer, better, notification-based system that > relies on other apps to tell it to add items to the list, which makes them > show up instantly, but relies on apps playing nice and adding their items to > the list. KDE software will do this, but GNOME apps will not, which is why > files saved by GIMP don't instantly appear. GNOME apps use a different, > cross-desktop API which frankly we should be using too. > > However I had thought that we were working around this by introspecting the > file that backs the cross-desktop thing that GNOME uses. Méven, do you > remember the details? It's getting hazy for me. I mentioned the "today" element because, funnily enough, when I first noticed this issue the files were correctly reported there but not in "recent files". On another occasion, though, it was the opposite. So yes, it's quite hazy. I will do more experiments and report back my findings (if any).
Is .local/share/RecentDocuments/ the cross-desktop method?
(In reply to Nate Graham from comment #3) > Forget about "Today" and those others. Those are the old Baloo-based items > that never quite worked right because they perform filesystem scanning, so > newly created items may take a while to show up there, making it useless for > this use case. IMO we should just remove them from the Places panel by > default (if we haven't already, I can't remember). > > `recentlyused:/files` is a newer, better, notification-based system that > relies on other apps to tell it to add items to the list, which makes them > show up instantly, but relies on apps playing nice and adding their items to > the list. KDE software will do this, but GNOME apps will not, which is why > files saved by GIMP don't instantly appear. GNOME apps use a different, > cross-desktop API which frankly we should be using too. > > However I had thought that we were working around this by introspecting the > file that backs the cross-desktop thing that GNOME uses. Méven, do you > remember the details? It's getting hazy for me. This just happened to me: - I saved two files in GIMP; - I opened the upload dialogue in Firefox; - the files were not present in "recent files" but were in "Today". The files were saved four minutes ago as I write this and they still haven't appeared in "recent files". So I can confirm that the issue that I reported earlier is as I described it.
.local/share/recently-used.xbel is the cross-desktop file (https://www.freedesktop.org/wiki/Specifications/desktop-bookmark-spec/) .local/share/recently-used.xbel is parsed regularly on file change by the process `kactivitymanage` by it relies on inotify which implies a delay. So Riccardo Robecchi do the recent files appear in "Recent Files" after ~2 seconds (i.e save files wait 2 seconds open upload dialog) ? And do you see a trace of your recently opened files in .local/share/recently-used.xbel ?
(In reply to Méven Car from comment #7) > .local/share/recently-used.xbel is the cross-desktop file > (https://www.freedesktop.org/wiki/Specifications/desktop-bookmark-spec/) > > .local/share/recently-used.xbel is parsed regularly on file change by the > process `kactivitymanage` by it relies on inotify which implies a delay. > > So Riccardo Robecchi do the recent files appear in "Recent Files" after ~2 > seconds (i.e save files wait 2 seconds open upload dialog) ? > And do you see a trace of your recently opened files in > .local/share/recently-used.xbel ? I finally found myself in the situation which shows the files in "modified today" but not in "recent files". I took a screenshot and it is correctly displayed in "modified today", but not in "recent files". It does not appear in .local/share/recently-used.xbel. The screenshot was taken about half an hour ago as I write this. This might happen much more frequently, I have been using the GTK file dialogue in Firefox specifically to avoid this issue and https://bugs.kde.org/show_bug.cgi?id=424209, which makes my workflow impossible. The KDE file dialogue reappeared after an update to neon-settings, which forces the use of the KDE dialogue.
What program did you use to take this screenshot ? spectacle ? The bug might concern the application here, that did not inform the system a file was modified. Do you see this file being referenced by a .desktop file in `~/.local/share/RecentDocuments/` ? That's the path where recent files modified by KDE Apps appear at the moment (it should change). Another thing to note recent files (recentlyused:/) does not refresh automatically and is not instantaneous, you might want to use F5 to refresh dolphin view. Last question do you have a `kactivitymanage` daemon process running ?
(In reply to Méven Car from comment #9) > What program did you use to take this screenshot ? spectacle ? > The bug might concern the application here, that did not inform the system a > file was modified. > Do you see this file being referenced by a .desktop file in > `~/.local/share/RecentDocuments/` ? That's the path where recent files > modified by KDE Apps appear at the moment (it should change). > > Another thing to note recent files (recentlyused:/) does not refresh > automatically and is not instantaneous, you might want to use F5 to refresh > dolphin view. > > Last question do you have a `kactivitymanage` daemon process running ? Yes, I used Spectacle. This is just one example, though; as I mentioned before, I had this same issue with other programs (e.g. GIMP). It seems like there *is* an issue with Spectacle though, so I will open a separate bug report about that. I understand that refresh for recent files is not instantaneous, but as I wrote it did not update after half an hour which is why I updated this bug report. I indeed do have a "kactivitymanager" process running. Thank you for your help in trying to solve this issue, Méven.
(In reply to Riccardo Robecchi from comment #10) > (In reply to Méven Car from comment #9) > > What program did you use to take this screenshot ? spectacle ? > > The bug might concern the application here, that did not inform the system a > > file was modified. > > Do you see this file being referenced by a .desktop file in > > `~/.local/share/RecentDocuments/` ? That's the path where recent files > > modified by KDE Apps appear at the moment (it should change). > > > > Another thing to note recent files (recentlyused:/) does not refresh > > automatically and is not instantaneous, you might want to use F5 to refresh > > dolphin view. > > > > Last question do you have a `kactivitymanage` daemon process running ? > > Yes, I used Spectacle. This is just one example, though; as I mentioned > before Well this is a per-app issue in fact, applications need to inform the system the files they have accessed. Here it is spectacle that is concerned. > I had this same issue with other programs (e.g. GIMP). It seems like > there *is* an issue with Spectacle though, so I will open a separate bug > report about that. GTK apps had a fix not so long ago for this so unless you find a regression, things should be fixed. https://phabricator.kde.org/D23112 > Thank you for your help in trying to solve this issue, Méven. Thank you for you support :) Now that the issue is well defined, a fix is not far. But I can't promise anything soon. For whoever wants to fix this : The issue is Spectacle does not use KRecentDocument or KActivity to keep track of the files it has created.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/33
Git commit 5bd7e9b83a092b46531191d6122482d5a5a6bcf2 by Méven Car. Committed on 25/10/2020 at 06:39. Pushed by meven into branch 'release/20.08'. ExportManager: Marked saved files as recent files Using KRecentDocument FIXED-IN: 20.08.3 M +9 -2 src/ExportManager.cpp https://invent.kde.org/graphics/spectacle/commit/5bd7e9b83a092b46531191d6122482d5a5a6bcf2
*** Bug 427381 has been marked as a duplicate of this bug. ***
(In reply to Méven Car from comment #9) > What program did you use to take this screenshot ? spectacle ? > The bug might concern the application here, that did not inform the system a > file was modified. > Do you see this file being referenced by a .desktop file in > `~/.local/share/RecentDocuments/` ? That's the path where recent files > modified by KDE Apps appear at the moment (it should change). > > Another thing to note recent files (recentlyused:/) does not refresh > automatically and is not instantaneous, you might want to use F5 to refresh > dolphin view. > > Last question do you have a `kactivitymanage` daemon process running ? Méven, I've been using the KDE dialogue for a while now and I realised that the real issue is that the "recent files" view does not refresh automatically. That's a large UX issue to me. Given that everything else works this way, I expect that if I close the dialogue and open it again, it will show me updated contents - it works this way for folders, as an example. Right now the user experience is inconsistent with every other part of the system. Making the "recent files" view automatically refresh the contents would make it act like every other component and therefore meet the expectation of the user. Should I open a new bug about this specific thing? Thanks again for your help.
Riccardo, if you believe the issue you are seeing is a different bug as described here, please add a new ticket. Otherwise, please reopen this ticket.
https://bugs.kde.org/show_bug.cgi?id=428085(In reply to Riccardo Robecchi from comment #15) > (In reply to Méven Car from comment #9) > > What program did you use to take this screenshot ? spectacle ? > > The bug might concern the application here, that did not inform the system a > > file was modified. > > Do you see this file being referenced by a .desktop file in > > `~/.local/share/RecentDocuments/` ? That's the path where recent files > > modified by KDE Apps appear at the moment (it should change). > > > > Another thing to note recent files (recentlyused:/) does not refresh > > automatically and is not instantaneous, you might want to use F5 to refresh > > dolphin view. > > > > Last question do you have a `kactivitymanage` daemon process running ? > > Méven, I've been using the KDE dialogue for a while now and I realised that > the real issue is that the "recent files" view does not refresh > automatically. That's a large UX issue to me. Given that everything else > works this way, I expect that if I close the dialogue and open it again, it > will show me updated contents - it works this way for folders, as an > example. Right now the user experience is inconsistent with every other part > of the system. Making the "recent files" view automatically refresh the > contents would make it act like every other component and therefore meet the > expectation of the user. > Should I open a new bug about this specific thing? Thanks again for your > help. This is a different bug you are reporting here perhaps https://bugs.kde.org/show_bug.cgi?id=428085 that was recently fixed in the yet to be released KDE Frameworks 5.77.
(In reply to Méven Car from comment #17) > https://bugs.kde.org/show_bug.cgi?id=428085(In reply to Riccardo Robecchi > from comment #15) > > (In reply to Méven Car from comment #9) > > > What program did you use to take this screenshot ? spectacle ? > > > The bug might concern the application here, that did not inform the system a > > > file was modified. > > > Do you see this file being referenced by a .desktop file in > > > `~/.local/share/RecentDocuments/` ? That's the path where recent files > > > modified by KDE Apps appear at the moment (it should change). > > > > > > Another thing to note recent files (recentlyused:/) does not refresh > > > automatically and is not instantaneous, you might want to use F5 to refresh > > > dolphin view. > > > > > > Last question do you have a `kactivitymanage` daemon process running ? > > > > Méven, I've been using the KDE dialogue for a while now and I realised that > > the real issue is that the "recent files" view does not refresh > > automatically. That's a large UX issue to me. Given that everything else > > works this way, I expect that if I close the dialogue and open it again, it > > will show me updated contents - it works this way for folders, as an > > example. Right now the user experience is inconsistent with every other part > > of the system. Making the "recent files" view automatically refresh the > > contents would make it act like every other component and therefore meet the > > expectation of the user. > > Should I open a new bug about this specific thing? Thanks again for your > > help. > > This is a different bug you are reporting here perhaps > https://bugs.kde.org/show_bug.cgi?id=428085 that was recently fixed in the > yet to be released KDE Frameworks 5.77. That seems to be the case. Thanks to both you and Christoph for your help.