GNOME Bugzilla – Bug 315207
gtkfilechooser should offer previews from GNOME
Last modified: 2012-10-17 20:10:03 UTC
i was very surprised there's not already a bug for this, maybe i just didn't find it. the point is that there's no (inline) preview at all in GtkFileChooser, which makes it very unpractical to browse directories of pictures. see screenshot attachment. in most of the cases, it's possible to work around it, drag&dropping the file in applications (thus avoiding gtkfilechooser), but for instance when uploading a file on a website, there is only a "browse" button and you can't drag&drop. then you must use nautilus, remember the file name, go in file chooser, or maybe drag&drop from nautilus to the filechooser if it works... in any case that's not intuitive and not very practical. of course i realise the problem is that gtk doesn't have access to gnome APIs, it's just that GtkFileChooser should offer an extension mechanism for such thumbnails.
Created attachment 51775 [details] feature in nautilus
Created attachment 80692 [details] gtkfilechooser open UI mockup. UI mockup. The major difference is the addition of zoom and list/icon view toggle controls in the top right corner.
I also am having the exact same issues with the gtkfilechooser. Selecting specific images from folders of images is a real pain, with the best approach to copy+paste the address from Nautilus. I am a bit worried that this bug was reported over a year ago with no response. I think a good way to do this is to offer both a list and icon mode in gtkfilechooser like it is done in Nautilus. Which brings up another question, should icon mode be used by default like it is in Nautilus or stick to the list mode? I've attached a rough UI-mockup that I've created. Also there is a somewhat lengthy thread discussing the issues (mostly performance related) involved as well as some general complaints on the existing interface on the Ubuntu forums here: http://www.ubuntuforums.org/showthread.php?t=340994 Please excuse the title of the thread, I know you guys work hard and I am very thankful for it, however gtkfileviewer was annoying me quite a lot that day... Thank you in advance.
Googled my way here; just to cast my vote on this feature here. Not having thumbnails can simply destroy usability for my aunts who seldom grasp the concept of a filename and have short memory. I saw old Windows versions using this, it is kind of humiliating ;)
This should be filed under the GtkFileChooser component.
Modifying component to GtkFileChooser :)
Does that mean bug 372344 should not be considered wontfix, but instead a duplicate of this one?
To answer comment #7; I think not, bug #372344 was about a preview pane appearing on the right of the file list when you select a file. This bug is about thumbnails inside the list of files. see mockups in comment #1 and comment #2.
Indeed it is slightly different, bug 372344 was about the preview "pane" it seems. However, when I thought of an icon view, I got this reply: quote: "the preferences are for nautilus, and a file selection dialog is not a file manager window. the file chooser does not have an icon view, and will not get one." (comment 2 of bug 372344) It just scared me a bit I guess.
about the icon view, as you can see in the attachment from comment #1 it's possible to have thumbnails without needing an icon view. Nautilus shows thumbnails in the same mode as the file chooser, in list mode. I don't really understand why the file chooser shouldn't have an icon mode, but certainly there is no reason why it shouldn't have at least thumbnails in the list mode.
Well, thumbnails in list mode are pretty darn small, no? Unless there are zoom +/- buttons that I failed to notice?
(In reply to comment #10) > I don't really understand why the file chooser shouldn't have an icon mode I'll be happy to review a patch for this. > certainly there is no reason why it shouldn't have at least thumbnails in the > list mode. This is easy to do with bad performance; a bit harder to do with good performance. Grep for gnome_icon_lookup in libgnomeui/file-chooser/gtkfilesystemgnomevfs.c - you'll see that it doesn't use a GnomeThumbnailFactory object. If you add one, it will get thumbnails in the file list.
about coding this feature: i thought gtk couldn't use gnome libraries such as GnomeThumbnailFactory(cross-dependency problem)? i think most people would be satisfied with previews for image types which GtkPixbuf can display, if we give up gnome thumbnailers (too bad for SVG images though). What is doable here? is there some way we could use the gnome thumbnailers? or we limit ourselves to GtkPixbuf? About performance.. you probably mean not keeping in memory images which are not displayed anymore, when the user changes the directory or scrolls in the list?
GdkPixbuf happily renders SVGs if you have librsvg installed.
(In reply to comment #13) > about coding this feature: i thought gtk couldn't use gnome libraries such as > GnomeThumbnailFactory(cross-dependency problem)? > i think most people would be satisfied with previews for image types which > GtkPixbuf can display, if we give up gnome thumbnailers (too bad for SVG images > though). This would be done in libgnomeui/file-chooser/gtkfilesystemgnomevfs.c, which already links to libgnomeui. So, using gnome-thumbnail-factory is not a problem. > About performance.. you probably mean not keeping in memory images which are > not displayed anymore, when the user changes the directory or scrolls in the > list? This is about loading thumbnails only when they get scrolled into the visible area. GtkTreeView doesn't let you do that easily.
GLib recently got MD5 support, so thumbnailing could be moved to gtk now.
the implementation of the file-to-thumbnail-path-to-pixbuf can be also found in libegg, under the pixbufthumbnail directory (as part of the EggIconChooser widget).
I am not sure if it is not too late but I would prefere a separate pane on the left. Why? - Because I often have folders with many files [which even in 'list' layout are not in the same 'page']. The previews in-list would make searching file longer if I know a file [1]. - It would also do not make hard to scroll the list while the thubnails loads. - Because it is already done in many applications (for example MS Office, GIMP...) and users are familiar with it. Possibly the best solution [for users - not developers ;)] would be implementing both and offer a configuration of behaviour. [1] I know I should use git but I name files simpy "yyyymmdd. filename" and if I know the filename part I can find the filename easily but I cannot put it in the path textbox as I don't know the begining of filename.
Nobody seems to have mentioned (and people don't seem to realize) that previewing is currently something added by the application. That's why you have a preview pane when opening files from the GIMP. Any generic solution would need to play well with that. But if this is just about thumbnail icons, or an icon view, then this bug should be renamed.
(In reply to comment #19) > Nobody seems to have mentioned (and people don't seem to realize) that > previewing is currently something added by the application. That's why you have > a preview pane when opening files from the GIMP. Any generic solution would > need to play well with that. But if this is just about thumbnail icons, or an > icon view, then this bug should be renamed. > I've mentioned - and unfortunatly it seems to be more useful for me in this form. Because: - As icons load it may make scrolling hard - In folders with many files it is more efficient - Users are more familiar with this type of preview (;)) May be it should be done by something like: gtk_file_chooser_set_preview(chooser, TRUE); or other indication of compatibility of application. Anyway IMHO the fact that applications are implementing it on their own means that the feature is in fact needed.
Gtk+ does show previews in the list mode by now. Either an icon view or a preview still seem like good ideas. I wonder if one of these would be enough, ie. if you have big icons that would make choosing images much more convenient, and you wouldn't need a separate preview anymore.
I am still a proponent of the "large thumbnail"/"icon" view. The 10x10 pixels thumbnails we have in list view are a joke, and the one-at-a-time preview pane on the right is inefficient, too. Please, rename this bug to reduce confusion?
Something like http://bugzilla.gnome.org/attachment.cgi?id=80692&action=view would be really useful when selecting images, for example, when selecting an image to be used as user image from gnome-about-me I have to remember full filename because: 1. If nautilus was not opened in image location I get no preview at all (at least with gtk-2.12.11 2. Even when I get preview in list mode (after browsing with nautilus location dir), it would be easier select the desired image in proposed mode, because with list view, it can be hard find proper image when directory contains a lot of them Thanks
*** Bug 498073 has been marked as a duplicate of this bug. ***
*** Bug 588697 has been marked as a duplicate of this bug. ***
This bug seems a duplicate of #141154.
Any plan to solve this issue in gtk+3.0?
Isn't this a duplicate of bug #141154 now then?
Let's make it so. - preview panes are the individual applications' responsibility - thumbnails in listview are completely useless - we're missing an iconview with thumbnails, which is what bug #141154 is about *** This bug has been marked as a duplicate of bug 141154 ***
(In reply to comment #29) > Let's make it so. > - preview panes are the individual applications' responsibility I think this is exactly the problem that people were complaining about. It shouldn't be.
Having a big thumbnails iconview for images and videos, reusing the fdo thumbnail spec, would solve 90% of the usecases. For more specialized usecases required by individual applications, then they can use the preview pane. This is how I understand it (the bug report here has many issues mixed up together, making this a bit more confusing, but the jist of the issue is #141154 I think).
BTW, making the preview pane *not* the application's responsibility, i.e. making it be handled directly by the file chooser, will happen soon. This will be part of the "content selection" project for Gnome OS. Thanks to nekohayo for marking this bug as a duplicate. Bug #141154 has the details on the new bgo141154-filechooser-icon-view branch.