GNOME Bugzilla – Bug 683999
Recent items list should recalculate itself when GTK FileFilter is used
Last modified: 2018-04-15 00:33:30 UTC
Let's say you have this piece of code: chooser = Gtk.FileChooserDialog(_("Open File..."), self, action=Gtk.FileChooserAction.OPEN, buttons=(Gtk.STOCK_CANCEL, Gtk.ResponseType.CANCEL, Gtk.STOCK_OPEN, Gtk.ResponseType.OK)) for format in formats: filt = Gtk.FileFilter() filt.set_name("foo project files") filt.add_pattern("*.foo") chooser.add_filter(filt) Now, the problem is that the filechooser limits the amount of recently used items shown by default... but does not take filters into account. So if you used a bunch of other files recently but not any *.foo files, you'll end up with an empty list because the filter is filtering an already limited list. If the FileFilter had access to the unlimited list, the "foo" files would show up.
This prevents being able to simply rely on the filechooser's "Recent items" view in pitivi's "Open project..." dialog.
Created attachment 248705 [details] [review] Only include recent files that match filter One way of doing it would be to check against the filter when getting the recent files. And only include the ones that match. This way it still checks against the limit, but only ticks up against it if the recent file matches the current filter. The problem with this is that the filter is applied more than once and is not needed later since only matching files are added to the model. Comments? What would be a better approach?
Another way of doing it would be to not apply any limit while getting the recent items (an unlimited list) And then add the possibility to limit visible nodes in the gtkfilesystemmodel, and set that limit to the gtk-recent-files-limit. Two patches below, one against gtkfilesystemmodel and one against gtkfilechooserdefault.
Created attachment 248719 [details] [review] Add limit to visible nodes
Created attachment 248720 [details] [review] Set limit on visible recent files
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new