GNOME Bugzilla – Bug 435342
Add recent files list to the file chooser
Last modified: 2007-07-21 15:29:47 UTC
the patch for adding search capabilities to GtkFileChooser allows the creation of operation modes to the embeddable widget. thus, in order to show the list of recently used files (and folders) a new mode can be added to the FileChooser, without the location entry and the list populated using the GtkRecentManager attached to the same screen of the widget. I'll work on the patch and attach it as soon as it's clean enough.
See also bug 138417.
Created attachment 87544 [details] [review] Implement "Recently Used" list in the file chooser this is the initial version of the patch. the missing bits are mostly the same issues of the search implementation (bug #435343): * filter dropdown does not affect Recent Files mode (in gedit you care only about text files, not about searchterm.jpg); * folders should go first (and have the right icon); * double-clicking on a folder tries to open it as a filename; also: * should we limit the length of the returned list of recent files? so, some of the solutions for bug #435343 should be applied to this patch too.
Created attachment 87561 [details] [review] Recent files list in GtkFileChooser changes: * use GTK_ICON_SIZE_MENU instead of GTK_ICON_SIZE_SMALL_TOOLBAR for the "search" and "recently used" items; * hide the path bar and the buttons when switching to the "recent files" mode;
Created attachment 87845 [details] [review] Recent files list in GtkFileChooser new cumulative patch, including: * patches from bug #435343, fixing the search mode * patches fixing similar search and recent files issues * list view UI experimentation (split basename and full path on two lines, like the recent chooser dialog does, in the search and recent files modes) maintaining two trees is becoming a bit too unwieldy, since most of the fixes for the search mode apply to the recent files mode, like the display of the search hits/recent files, the clean ups for the model when switching between modes, etc. diffstat /tmp/gtk-filechooser-search-recent.diff gtkfilechooserdefault.c | 1396 ++++++++++++++++++++++++++++++++++++++++-------- gtkfilechooserprivate.h | 12 2 files changed, 1199 insertions(+), 209 deletions(-)
screenshots of the file chooser in search mode and recent files mode with the patch applied: http://www.gnome.org/~ebassi/filechooser-search.png http://www.gnome.org/~ebassi/filechooser-recent.png
(In reply to comment #5) > screenshots of the file chooser in search mode and recent files mode with the > patch applied: > > http://www.gnome.org/~ebassi/filechooser-search.png > http://www.gnome.org/~ebassi/filechooser-recent.png Nitpick, it would be better if it said "testfoo2(2).c in Downloads" rather than "/home/ebassi/Desktop/Downloads/testfoo2(2).c"
(In reply to comment #6) > > http://www.gnome.org/~ebassi/filechooser-search.png > > http://www.gnome.org/~ebassi/filechooser-recent.png > > Nitpick, it would be better if it said "testfoo2(2).c in Downloads" rather than > "/home/ebassi/Desktop/Downloads/testfoo2(2).c" what if I have two folders with the same name on two different paths? the search and recent files mode have absolutely no context on the base path, so they must provide some way to avoid ambiguity.
Created attachment 87863 [details] [review] Recent files list in GtkFileChooser (v4) new cumulative patch. changelog: * assign the model when done when in OPERATION_MODE_RECENT; * set focus on the search entry; * add mnemonic binding from the search label to the search entry; * de-boldify search entry label; * small change in gtk_recent_info_get_icon(), which now returns GTK_STOCK_FOLDER for the "x-directory/normal" MIME type (will go upstream soon-ish) diffstat /tmp/gtk-filechooser-search-recent.diff gtkfilechooserdefault.c | 1410 ++++++++++++++++++++++++++++++++++++++++-------- gtkfilechooserprivate.h | 12 gtkrecentmanager.c | 7 3 files changed, 1217 insertions(+), 212 deletions(-)
re comment 7: the special-casing Bastian proposes would probably apply only to the special user dirs (from xdg-user-dirs). Also context can and should be provided by tooltips, now that we can do tooltips in treeviews. We also need such tooltips in some other places (e.g. the combo of the file file chooser button)
Created attachment 87951 [details] [review] Recent files list in GtkFileChooser (v5) complete patch, feature complete with also the missing bits of bug #435343. the split-up, per commit, patches are available at: http://www.gnome.org/~ebassi/filechooser-merge/ changelog: * make the current filter work in both recent files and search modes; * also make sorting work in both modes; * allow bookmarking folders in both recent files and search modes; diffstat /tmp/gtk-filechooser-search-recent.diff gtkfilechooserdefault.c | 1932 +++++++++++++++++++++++++++++++++++++++++------- gtkfilechooserprivate.h | 16 2 files changed, 1684 insertions(+), 264 deletions(-)
Thanks for this work. I tried to look over the patches: 0001: Would be nicer if we wouldn't add the keybinding unless search is available, but not a blocking issue 0007: I don't think sneaking that G_LIKELY in the error path is worth it. 0008: After applying this patch, going search->recent->search (by clicking on the shortcuts) segfaults: Gtk-ERROR **: file gtkfilechooserdefault.c: line 9026 (search_activate): assertion failed: (impl->search_hbox == NULL) Maybe thats fixed in later patches, 00011 looks like it might... I don't think the separator between Search and Recent files adds anything, really. It looks a bit odd to me to have a bunch of single items with separators between them. Would be nice if we could get the same icons between the panel places menu and the file chooser for search and recent files. 0016: not sure I agree with this change for slow searches 0018: ...but I see you found that, too 0019, 0020: there is a bug here (preexisting, I guess): At some point federico allowed bookmarking files, but that seems to work only via dnd, not via the add button. Even with these patches, dnd does not seem to work at all for recent files or search results 0027: Ater this patch, clicking on the name column in recent mode segfaults
one more thing: in select/create-folder mode, the search and recent files code should behave the same as the regular file lists.
(In reply to comment #11) > 0001: Would be nicer if we wouldn't add the keybinding unless search is > available, but not a blocking issue as I said on IRC, the keybinding might also be a problem (in their current form) if they clash with the dialog's mnemonics. we can test the presence of a search engine implementation in gtk_file_chooser_default_class_init(), by adding a _gtk_search_engine_is_available() to gtksearchengine.h. however, that functio might always return TRUE if GtkSearchEngineSimple was fixed to work without threads. > 0007: I don't think sneaking that G_LIKELY in the error path is worth it. okay, removed. > 0008: After applying this patch, going search->recent->search (by clicking on > the shortcuts) segfaults: > > Gtk-ERROR **: file gtkfilechooserdefault.c: line 9026 (search_activate): > assertion failed: (impl->search_hbox == NULL) > > Maybe thats fixed in later patches, 00011 looks like it might... yes; the patchset is incremental, and later patches might revert some issues. > I don't think the separator between Search and Recent files adds anything, > really. It looks a bit odd to me to have a bunch of single items with > separators between them. agreed. we can have a layout like: search recently used --- home desktop ... will fix it. > Would be nice if we could get the same icons between the panel places menu > and the file chooser for search and recent files. Lapo Calamandrei was working on a rework of the gtk-find stock icon and also on a stock icon for the recent files. > 0016: not sure I agree with this change for slow searches > 0018: ...but I see you found that, too it still makes sense for the recent files list, as the loading is sufficiently fast. we might switch later on anyway. > 0019, > 0020: there is a bug here (preexisting, I guess): At some point federico > allowed bookmarking files, but that seems to work only via dnd, not > via the add button. Even with these patches, dnd does not seem > to work at all for recent files or search results will fix it. > 0027: Ater this patch, clicking on the name column in recent mode segfaults yeah, it's a stupid bug due to the lazy loading. > one more thing: in select/create-folder mode, the search and recent files > code should behave the same as the regular file lists. will fix this too.
Created attachment 87988 [details] [review] Remove separator between Search and Recently Used shortcuts incremental patch Remove separator between Search and Recently Used shortcuts This commit fixes this issue found in review: > I don't think the separator between Search and Recent files adds anything, > really. It looks a bit odd to me to have a bunch of single items with > separators between them. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserdefault.c | 18 ++---------------- 1 files changed, 2 insertions(+), 16 deletions(-)
Created attachment 87989 [details] [review] Set sensitivity of rows consistently across actions incremental patch Set sensitivity of rows consistently across actions This commit fixes this issue found in review: > in select/create-folder mode, the search and recent files > code should behave the same as the regular file lists. The sensitivity of the rows in OPERATION_MODE_SEARCH and in OPERATION_MODE_RECENT is now set according to the action of the GtkFileChooserDefault widget. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserdefault.c | 117 +++++++++++++++++++++++++++++++++++-------- 1 files changed, 95 insertions(+), 22 deletions(-)
the shortcuts adding via drag-n-drop is much more complex than I thought initially; the actual source for the drag data is inside GtkFileSystemModel, which means that we need to switch in and out the drag source when changing the operation mode. I'll have to investigate more on that in order to get a clean enough approach. the segfault when changing the sorting based on the path is a bit more fuzzy; I don't understand why it happens only in recent-files mode, as the code is exactly the same in both the search and recent-files modes.
The incremental patches look fine and seem to address most of the concerns. I would be fine with getting the current patches in and working on the remaining issues in a separate bug.
Created attachment 88025 [details] [review] Subclass GtkTreeModelSort for the recent files model Patch 1/2 - Subclass GtkTreeModelSort for the recent files model In order to add a path to the shortcuts from the recent files model via drag and drop we have to override the GtkTreeDragSourceIface implementation of the GtkTreeModelSort. This is done by subclassing GtkTreeModelSort into RecentModelSort. This patch creates the subclass. The actual override functions are in the next commit. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserdefault.c | 93 ++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 92 insertions(+), 1 deletions(-)
Created attachment 88026 [details] [review] Override GtkTreeDragSource in the recent model Patch 2/2 - Override GtkTreeDragSource in the recent model Provide an implementation of GtkTreeDragSource::row_draggable() and GtkTreeDragSource::drag_data_get() vfuncs. The overridden functions allow adding a shortcut in OPERATION_MODE_RECENT by dragging and dropping a folder onto the shortcuts pane. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserdefault.c | 32 +++++++++++++++++++++++++++++--- 1 files changed, 29 insertions(+), 3 deletions(-)
(In reply to comment #17) > The incremental patches look fine and seem to address most of the concerns. > I would be fine with getting the current patches in and working on the > remaining issues in a separate bug. I've attached the working implementation of the "add-shortcut-via-dnd" for the recent files mode; the search mode implementation will be exactly the same (subclass GtkTreeModelSort and override GtkTreeDragSourceIface). I shall finish it today or at worst tomorrow. then I can commit the whole patchset (using fewer SVN commits, if needed) and work on the weird crasher of comment #11.
Created attachment 88029 [details] [review] Add shortcut via drag and drop in search mode Add shortcut via drag and drop in search mode Like for OPERATION_MODE_RECENT, subclass GtkTreeModelSort to override GtkTreeDragSourceIface vfuncs and allow dragging and dropping rows containing folders from the search list to the shortcut pane. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserdefault.c | 114 ++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 113 insertions(+), 1 deletions(-)
Great work Emmanuele. I haven't tried it yet, but from looking at the draggable implementations, files are still not draggable ?
(In reply to comment #22) > Great work Emmanuele. I haven't tried it yet, but from looking at the draggable > implementations, files are still not draggable ? yes, files are not draggable but folders are. I can enable dragging of files too, it's just a matter of removing the is_folder check, but I'd have to check the logic for shortcuts_insert_path() and make sure you cannot drop a filename inside the shortcuts pane unless it's a folder.
I think we want regular files to be both draggable and droppable Try the add button and you'll see that we already allow regular files as bookmarks. We just failed to fix the dnd for that.
the add button becomes unsensitive if I select a file (on both my ubuntu and with the stock gtk+), and returns sensitive when I select a folder; when I drag-and-drop a file, it works. so I guess it's the other way around: dnd works but the sensitivity check doesn't. unless I'm doing something really weird. anyway, I can open a bug for this and fix the bookmarks handling in every operation mode.
Yeah, I guess it might be worth checking with federico on his intentions there.
(In reply to comment #26) > Yeah, I guess it might be worth checking with federico on his intentions there. opened bug #437989 for this one.
Created attachment 88100 [details] [review] Move filename into tooltips just for sake of UI churning: I've moved the full path of the search hits and recent files into a tooltip; the result is quite pleasing, so I don't know what's best between the two options. Move filename into tooltips When the GtkFileChooserDefault is in OPERATION_MODE_RECENT and in OPERATION_MODE_SEARCH show the full path of the entry using a tooltip on the browse_files_tree_view widget. This removes the need for two-line entrie s in those modes while keeping the needed full path. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserdefault.c | 102 +++++++++++++++++++++++++++++++++++-------- 1 files changed, 84 insertions(+), 18 deletions(-)
the segfault has been fixed by kris in rev 17848. the last bit remaining is deciding whether applying the patch in comment #28 or not.
I like the general idea of that patch, but the current implementation does not feel quite right to me: 1) the tooltips on the file list have a gray background here, not a yellow one as "regular" tooltips 2) the tooltips are too slow to appear 3) the tooltips do move with the cursor This may all be problems with the new tooltips code, though, not necessarily with your patch.
(In reply to comment #30) > I like the general idea of that patch, but the current implementation does > not feel quite right to me: I've re=used the code from kris' tooltips test, so it can be improved. > 1) the tooltips on the file list have a gray background here, not a yellow > one as "regular" tooltips this is a themeing issue, and since the patch doesn't completely override the tooltip window, I think it's a problem with the new tooltip API. > 2) the tooltips are too slow to appear same as above. > 3) the tooltips do move with the cursor I assume s/do/don't/. I don't know how this might be fixed, but kris might.
by the way: I'll port the entire FileChooserDefault to the new tooltips API.
It would be very useful to have additional info in all views, not just the search/recently-used views. Minimally, file size and full path, but it could also be useful to have mime type, creation date etc., and perhaps a bit of other metadata info for specific types (image dimensions etc.).
Oops, I just read Comment #32, it looks like you are already planning to do what I suggested in Comment #33.
Having extra information in tooltips is nice, but it is not quite the same as having it directly in the file list - a size column would e.g. allow you to sort the list by size.
new patch arriving, using gtk_tree_view_set_tooltip_row() thus solving issue 3) of comment #30.
Created attachment 91744 [details] [review] [PATCH] Show tooltips on the files list when in search and recent files mode This patch moves the full path of the files shown in the GtkFileChooser default widget when in OPERATION_MODE_SEARCH and OPERATION_MODE_RECENT from the files list to a tooltip, using gtk_tree_view_set_tooltip_row() to correctly position the tooltip window. The cell renderer of the file column now only displays the name of the file. --- gtk/gtkfilechooserdefault.c | 109 +++++++++++++++++++++++++++++++++++-------- 1 files changed, 90 insertions(+), 19 deletions(-)
I think we can close this bug, as the last patch has been committed to trunk: 2007-07-20 Matthias Clasen <mclasen@redhat.com> * gtk/gtkfilechooserdefault.c: Apply a patch by Emmanuele Bassi to add tooltips to the file lists in recent files and search modes. and that the last remaining issue (bookmarking) is to be handled by bug 437989.