GNOME Bugzilla – Bug 137176
automatically create previews in Open dialog
Last modified: 2004-10-08 19:29:59 UTC
Open dialog doesn't preview images as it implies it can, except where the image has been opened before, which is pointless. Presumably it's accumulating thumbnails somewhere, which it shouldn't. Windows XP Professional Gimp 2.0pre4 GTK+ 2.2.4
Click the preview area (or press Alt-P) to create the preview. Select multiple files to create previews for all of them. No, this is not pointless. It can take significant time to create the preview. What we can do here is to introduce a heuristic and attempt to create previews for small images. This is a planned enhancement that might make it into GIMP-2.2.
Okay, that resolves it. But it is not obvious at first. My initial thought was to click the 'button' with the word "Preview" on it in the Preview pane to make the preview. This would have made sense to me, but it did not work. Maybe THAT is a bug. The P is underlined, which in Windows indicate a shortcut key. I've just now found out it's Alt-P. A note under the panes like "Press Alt-P or click Preview pane for Preview of selected files" may be in order, as long as it's unobtrusive. Maybe in a dark grey font. Indeed, in Photoshop, if you have Preview on, and the first image in the folder is huge, you're stuck until it finishes the preview. A self-explanatory option to make the preview makes the most sense to me, as indicated above. People will learn the shortcuts as they experiment, but accessible hints like in the menus should be present. If it does accumulate the thumbnails in some cache somewhere, an option to clear it periodically should exist. There may be for all I know. It's just if you deal with a lot of images, they will accumulate over time, taking up space, even when they're small. If, as in Linux, you have a ".thumbnails" dir, then at least the user can see them and deal with them. Similarly, like Windows, if a Thumbnails database file is created in the Dir. Hell, if you can access the Windows Thumbnails db file, it could save you some time and trouble.
There's a tooltip that explains how to get a preview. Changing the summary back. We follow the thumbnail managing standard as proposed on freedesktop.org. It's not our job to clean the thumbnails, but you can simply remove the thumbnail folder from time to time. Also, I already have some code written that allows to manage the thumbnails but it's not at all GIMP specific.
A good application will keep its system files under check. I was gonna ask where the thumbnail folder was, but I managed to locate it. The average user may not know where to find it, or think to look for it, and doing a search by filename won't find it. A graphics program would tend to appeal to visual types who are application-specific, more than system administrator types. I've only experimented a little with it with a set number of images, and the thumbnail folder now has 33 files, totalling 800kb, nearly 1Mb once Windows had placed a thumbnails db file in it. A much more intense use of The Gimp will see this folder grow out of control if it is not culled. A browser cache can be set to expire, or limited to a certain size, and the location of that cache is always listed prominently in the preferences. If not, the average internet-surfer would quickly run out of disk space and wonder why. I think it would be a good idea to have a section, perhaps under Folders, showing where the thumbnail cache is, with an option to set a size limit like a browser, culling the oldest. The Folders prefs already have 2 of these attributes, namely path and bin/clear button, but would need the above as well. So I do think it IS the job of the application to keep system-generated thumbnails under check.
There is no point to discuss this here. Please join the mailing-list on freedesktop and bring the topic up for discussion there. Since these thumbnails are shared between various applications, control over the thumbnail folder should be clearly defined in the standard.
freedesktop.org is mainly concerned about free desktops, which does not include all desktops that the GIMP runs on. Although it makes sense for the GIMP to delegate the thumbnail management to another application (e.g., a file manager) on free desktops that have such applications, the users have a problem for the non-free desktops or for environments that pre-date the freedesktop efforts. In this case, we are assuming that this is "somebody else's problem", but there is no "somebody else". It may be worth opening a separate bug report related to that. Let's keep this one focused on automating the preview generation.
Even if we made this our problem on some platforms, the standard still needs to define what settings are involved, which files should be deleted and so on. It is a matter of extending the spec before implementing any changes.
The problem with the tooltip is it is only visible (after a small delay) if 1. an image is selected, and 2. you have the pointer over the Preview pane. A better-phrased version (plain English is better, 'Control-click' instead of '<Ctrl> Click', also note case) IN the preview pane underneath the existing text would be better, or perhaps underneath the panels once a file is selected (less-obtrusive 'tooltip'). As for the Thumbnails, you're saying the Gimp developers are tying The Gimp to Gnome and other desktops which choose to adopt this standard, and should be implemented as System controls. Not good for cross-platform compatibility. I maintain a Mandrake install and check out new versions now and then to check on progress, but I'm not sufficiently versed to suggest modifications to a standard I know nothing about and not overly concerned with. I'm concerned for now with the usability of The Gimp on Windows, and hopefully eventually on the Mac. I do not know which parts are down to the Gimp, the GTK+ toolkit, or some proposed Desktop standards. For instance, the Open dialog may be due to the GTK+ toolkit for all I know, not Gimp, and may need to be fixed by other developers on some other bugtracker. I'm merely pointing out what I see as bugs or needed enhancements on the Windows version of The Gimp if it is to be a worthy alternative to Photoshop. It may be of interest to the Windows maintainer, Tor Lillqvist, and whomever maintains MacGimp. I don't know if you allow local differences across the different platforms, but it would be an idea for the Mac and Windows versions at least to have such preferences. Hard disk space can be pressing at times when you deal with a lot of images/multimedia and large graphics/web authoring apps. Allowing thumbnails from years of image editing to pile up in a hidden configuration folder without check or even making the user aware of it is NOT a good idea. Windows has enough of this already.
Please, by all means, stick to the subject of the bug-report. If you want to discuss handling of the thumbnail cache, then open a new bug-report for it. A bug-report may only ever handle a single subject.
In order to keep this bug focused on the topic described in the summary, I have submitted a new bug report (bug #137268) dealing with the deletion of thumbnails. Please direct all discussions related to thumbnail management to that bug report. This one should only be about how thumbnails are created.
2004-10-08 Sven Neumann <sven@gimp.org> * app/config/gimpcoreconfig.[ch] * app/config/gimprc-blurbs.h: added new gimprc option "thumbnail-filesize-limit" that allows to control the maximum filesize for automatic thumbnail creation. * app/dialogs/preferences-dialog.c: added a GUI for it, needs review. * app/core/gimpimagefile.[ch]: minor cleanups. Moved call to gimp_thumbnail_peek_image() from gimp_imagefile_save_thumb() to gimp_imagefile_save_thumbnail() to avoid it being called twice. * app/file/file-utils.[ch]: export utility function file_utils_find_proc_by_extension() that allows to check for a file plug-in by looking at the filename extension only. * app/widgets/gimpthumbbox.[ch]: automatically create or update thumbnails for image files with a known extension that are smaller than "thumbnail-filesize-limit". Fixes bug #137176.