GNOME Bugzilla – Bug 137278
"Open Recent" menu should not show non-existant files
Last modified: 2016-10-17 04:39:38 UTC
The "Open Recent" menu should not show non-existant files, and should probably not show files on unmounted media. Alternatively, the unloadable files could be marked as unloadable, perhaps by greying them out.
Moving to libegg/recent-files.
Still broken.
*** Bug 114588 has been marked as a duplicate of this bug. ***
*** Bug 301898 has been marked as a duplicate of this bug. ***
Please can non-existant files be greyed out with a tooltip explaining that the file no longer exists?
This ends up looking really broken, particularly in the panel. Upping priority.
I wrote a patch for graying out non-existing files. If it looks good, I'll commit it ASAP. As for the tooltips: it would require bug #111988 to be fixed, which would require some more work done, and adding features to code which will (soon) be scrapped seems like a waste to me.
Created attachment 48766 [details] [review] De-activate non existing items Proposed patch for greying out items pointing to non-existing (local) files.
Update: if we toggle sensitivity on the item pointing to a non existing file, then the tooltip does not show (obviously - why did I have to even check it?). So, the patch above should be enough to warn the user that an item inside the list is not available anymore without removing it - rationale: the file might be on a currently not mounted network share, or on a removable drive, so it makes sense to leave it in the list until it naturally expires.
Another update: this patch means an poll() storm - since it hits the disk for every item in the list returned by the model (thanks to pbor for pointing this out on #gnome-hackers). In GEdit, each time a non-existing item has been hit, it is removed from the list; it is a viable solution - but it's entirely up to the eggrecent users to do it. This if we care about I/O performance.
Don't grey anything out that the user has no clue how to ungrey. That's broken. If you don't want to remove it altogether (which you have a point about for removeable devices, I think), at least hide it completely from view. [cc'ing usability-maint, who I'm sure will have something useful to say on this ;)
Yeah, Luis hit the nail on the head with that one. :-) If it were possible to be 'smart' about files that were deleted vs. files that were on a removable device; that might be ideal way of doing a hided vs. shaded item. But without that just hiding the items sounds like the best option to me.
Actually I'm not sure you'd want files on removable devices to be greyed out, even if it were possible. If I've just borrowed a friend's USB stick to copy his foobar.conf file, I don't really want it to see it on my recent files list ever again, unless I happen to reconnect the same USB stick and it's still there.
the problem is still that we must check each file in the list; this could negatively impact on the menu latency (I have no numbers to show, at the moment - I'll try and come up with some). the right solution would be to make the panel remove the files that it hasn't been able to launch.
Created attachment 49606 [details] [review] make the panel remove a recent document if unable to launch it
I don't think this latest patch solves the problem in the right way. I'd like to know before I click that a file doesn't exist. How about both? Displaying the menu first, then checking the files exist and greying out those that don't?
as I said, checking every file in the list would mean the we should use GnomeVFSFileInfo; even if we restrict the check only to local URIs (file:// scheme) we end up with a series of stat(). the patch that greys out items could be reworked to disable them instead, but the performance issue stays. as for me, I've no hard feelings for making this change; but I'd like to do some profiling first: having the menu increse its latency would be a regression, IMO.
I agree to sentence 2 in Comment #16 Couldn't we start checking as soon as the "places" menu has come up? I guess it should have checked all files by the time the user opens the "recent documents" menu. In the meantime, an entry "updating" or something could be placed in the menu, just in case. I do not like the idea of greyed out items either, except maybe for removable media, but that should be accompanied by a tooltip with a some explanation.
On a side note, I noticed that my "Recent Documents" menu is empty at the moment, but I still get a "clear recent documents" option.
This problem remains.
(comment #18): > Couldn't we start checking as soon as the "places" menu has come up? the panel could launch an idle function, checking whether an item inside the list is present or not, one at a time, and removing the items not present using gtk_recent_manager_remove_item(); maybe a bit racey (what if the list changes while we are in the idle loop?) but this should spread the calls to stat(). still, the problem remains. nautilus should pick up deletions and remove the items from the recently used list - but this covers us only from the UI. but first the panel must be ported to the new GtkRecent code. I might have some time before GUADEC to do it.
Old patches are obsolete. Emmanuele: I'm not sure we shoud remove the files with gtk_recent_manager_remove_item(); since they could live on a removable hard drive. So they should just be hidden. And IMHO, GTK+ should handle this, at least for local files, since this is valid for all applications, not just the panel. Moving there.
(In reply to comment #22) > Emmanuele: I'm not sure we shoud remove the files with > gtk_recent_manager_remove_item(); since they could live on a removable hard > drive. So they should just be hidden. And IMHO, GTK+ should handle this, at > least for local files, since this is valid for all applications, not just the > panel. just set the "show-not-found" property to FALSE and every GtkRecentChooser will not display the items it can't find - if the item is local AND stat() can find it, then it'll be shown; if the item is not local, then it won't be shown. I can change the last part, and show every non-local file, though: I have no hard feelings for or against either solutions. until we have gvfs, though, I can't check whether a non-local file exists, so that is the current limit.
This is not exactly the same problem, but it's related and might be easier to fix. Whenever I've viewed a file in Evince or some other Gnome app that was opened by a web browser, it ends up in the recent documents list. Clicking on those files in the list comes up with an error that they don't exist, because they were just in /tmp Maybe recent documents could not list files in /tmp?
(In reply to comment #24) > Whenever I've viewed a file in Evince or some other Gnome app that was opened > by a web browser, it ends up in the recent documents list. Clicking on those > files in the list comes up with an error that they don't exist, because they > were just in /tmp > > Maybe recent documents could not list files in /tmp? I often use /tmp as a staging area for files, so no: I don't think this should happen. the applications might mark temporary files as private, so they would not appear in the global list.
Now that we have GIO at our hands, could we set up a file monitor and watch the files in the recent list for removal? If they are not in place any more just hide them. I am not familiar with GIO capabilities but I strongly assume we have some decent file monitoring facilities that are not prone to poll() or stat() storms.
(moving to generic improvement: having an "high" urgency did not magically fix this bug, and the infrastructure to fix it is already in place - it just needs to be done) there's an issue that arises if we start monitoring loads of file: the number of file monitors per-user might be limited (like it is the case with inotify on Linux). if you're using an indexer, the number of available monitors might quite quickly be exhausted. also, GIO might fall back to polling the stat() of each file. file monitoring should not be done by every application using a GtkRecentManager: it's pointless and will definitely lead to performance issues (imagine: all you running applications start monitoring every file in the list at the same time). a practical solution is what I outlined in comment #21 - a long-lived process that does the monitoring, since every change in the list will be reflected by every application which is actively monitoring the recently used storage file.
*** Bug 639513 has been marked as a duplicate of this bug. ***
It's bean a while since there was last any activity on this bug, and I was wondering what was happening with it. I notice there's been talk of monitoring the files and hiding them if they can't be found. Wouldn't a simpler solution be to not monitor them, and instead prompt the user to take action on missing files only when they try to open them, either asking them if they want them removed from the list (thus giving them the option to go out to the filesystem and move them back) or offer them a dialog with which they point to the new location?
*** Bug 767284 has been marked as a duplicate of this bug. ***
After years, nothing really has changed in this story — nor have patches manifested themselves — so let's close it. Monitoring files is expensive, especially if all applications start doing that at the same time. It's also not going to work for remote resources, or for resources on a removable volume. If a resource is not available, applications can remove it from the list when the user tries to open it; but given that files can randomly disappear or re-appear whenever a user adds a new volume, removing files from the list is probably much more user hostile than just leaving it there, and let it drop out of the list through the GtkSettings:gtk-recent-files-max-age setting, which caps the age of the recent files.
Come on, every time you i.e. move something to a subfolder and not open it directly afterwards, the recentlist-entry is dead. This really could be a pain for people who use the recentmanager a lot, and organizing your stuff just breaks it, no worries? To be clear, in Windows this actually works, and is a very neat feature. Really, there are projects like wine, but something this simple (in comparison) just get's left out? Isn't it kind of against the mantra of Linux to have every application implement its own workaround for a bug (check every file for existance before opening it and annoy the user if it isn't there anymore, or fustrate her by just doing nothing because there is nothing to open)?: Having good-quality libraries and services, which can be utilized by higher-level apps with little overhead? Also, is there possibly some obscure filesystem-signal which gets emitted every time something gets moved or deleted? Or for instance, if GTKRecent were to use CRC-hashes, it would be more memory-hungry, but had to do less list-searching etc. to find out whether a filesystem-change affects one of its files.