After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 514260 - Better filtering for "Recently Used" files
Better filtering for "Recently Used" files
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.12.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks: 548467
 
 
Reported: 2008-02-04 10:55 UTC by Bastien Nocera
Modified: 2009-07-30 10:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Bug #514260 – Better filtering for "Recently Used" files (1.60 KB, patch)
2009-05-30 12:00 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review

Description Bastien Nocera 2008-02-04 10:55:18 UTC
Currently, using MRU and application filtering, I list 5 recent files in Totem's main menu.

The recently used list in the file chooser isn't very usable, as it caps to 50 hits for _all file types_. This means I end up with 3 files that match what Totem is capable of playing. 
$ grep "Totem Movie Player" /home/hadess/.recently-used.xbel | wc -l
471

So they're definitely a lot of trimming.

The "Recently Used" bookmark should either show 50 hits for the application name, or better, 50 hits that match the mime-types supported, as exposed in the file choose filter.
Comment 1 Emmanuele Bassi (:ebassi) 2008-02-04 11:19:12 UTC
the recently used list is already filtered using the file chooser filter. it is clamped *after* the files have been sorted by MRU, and the resulting list is automatically filtered by the file chooser itself (like it does for the list of files).

if I filter the list before it's displayed you'll lose the ability to choose between the filters without reloading the entire list.
Comment 2 Bastien Nocera 2008-08-19 15:27:15 UTC
(In reply to comment #1)
<snip>
> if I filter the list before it's displayed you'll lose the ability to choose
> between the filters without reloading the entire list.

If that's technically possible, what would the hit be in terms of performance? It's probably better to have something useful rather than something fast but not too useful.
Comment 3 Milan Bouchet-Valat 2009-05-30 09:23:49 UTC
Wouldn't increasing the size of the initial list the file chooser gets from GtkRecentManager do? That's not absolutely perfect, but you could at least greatly increase the number of results, with a trivial fix.
Comment 4 Emmanuele Bassi (:ebassi) 2009-05-30 10:32:00 UTC
(In reply to comment #2)
> (In reply to comment #1)
> <snip>
> > if I filter the list before it's displayed you'll lose the ability to choose
> > between the filters without reloading the entire list.
> 
> If that's technically possible, what would the hit be in terms of performance?

might be noticeable; essentially, the same delay that happens when you open the Recently Used location - minus some one-time stuff.

I'm going to work on it so that at least we have some number...

Comment 5 Emmanuele Bassi (:ebassi) 2009-05-30 12:00:03 UTC
Created attachment 135608 [details] [review]
Bug #514260 – Better filtering for "Recently Used" files

Instead of refiltering the recently used files we should rebuild
the list altogether when the current GtkFileFilter changes; this
allows us to keep showing the maximum amount of recently used
files.

Fixes bug:
Comment 6 Emmanuele Bassi (:ebassi) 2009-07-30 10:32:37 UTC
pushed to master. for what is worth, I could not see any difference, so maybe I was just being overly cautious. :-)