GNOME Bugzilla – Bug 84927
Thumbnails on folders - RFE from WinXP
Last modified: 2010-07-03 06:01:21 UTC
From "embrace and extend" territory: From http://www.pcworld.com/features/article/0,aid,81996,pg,2,00.asp XP: A New Thumbnails View The Thumbnails view in XP has a new twist. If a folder contains images saved in a common Web format, such as .gif, .png, or .jpg, XP will create an icon for the folder that displays up to four of the images it contains, providing a glimpse of its contents. To show a single image, right-click the folder icon, choose Properties, and click the Customize tab. Or open the folder, right-click an empty area of the window, and choose Customize This Folder. (Alternatively, you can choose Customize This Folder on the View menu.) Click the Customize tab, and under 'Folder pictures' select Choose Picture. Select the picture you want to show in the thumbnail (see the following bonus tip), and click Open. If the preview image is to your liking, click OK. If not, click Choose Picture again to find another picture, or select Restore Default to remove the picture from the folder thumbnail. -- Sounds rather like a nice feature. Could possibly be implemented as a "hack" on the emblems feature.
I don't really like the way windows XP does it, i just find the folder sort of ugly. But perhaps we can add the camera emblem to folders that contain image. This would be more elegant, and would probably be easier to implement as well. What do you think bruce???
That's something I hadn't thought of, but probably a good idea. In fact, there might be a reason to identify folders in general in such a way - e.g. if a folder/directory contains only/mostly a certain type of file (special cases being: source code (folder contains Makefile*), music/sound (MP3, WAV, AIFF), image (JPEG, PNG, TIFF), video/animation (MPEG, AVI, MNG, SWF)), apply a certain emblem automatically. The implementation details might be a royal pain, though: which emblem, and how often. What is the "right thing" to do in cases where, e.g. there is just one image and a lot of plain text? Suggestion might be if one type of file is >= 50% of all files. Regardless of whether using "random image(s) collected from inside folder" or "standard emblem regardless of contents" method: This probably needs to be a "deferred" action, since it might involve reading the magic on potentially a great many files in each affected folder. It should probably also set some kind of metadata flag to avoid rescanning "too often;" simplest might be "only if the directory has been modified" (assuming that nobody opens a bunch of JPEG's, truncates them, and rewrites them as MP3's with the same filenames... is my POSIX-think remembering right that the mtime would be changed by normal "open, write, close" sequence?) -- better still might be "directory has been modified, and we have not rescanned in (n) seconds/minutes" -- Once such a system is in place, giving a user option to use thumbnail in place of "standard" emblem would probably not be difficult, and would ease the transition (one less thing for former XP users to gripe about); however, that's also one more switchable option to do battle with Nautilus's already-crowded preferences and the hp@rh-led crusade against "too many preferences," which is a very valid concern in itself. The "hard part," IMHO, is figuring out when to do the scan, and when to apply the emblem; the actual details of the emblem itself are relatively trivial AFAICS.
One standard way to automatically thumbnail a folder is to look for an image called ".folder.jpg" or similar. I'm pretty sure that's one of the methods WinXP uses.
Many audio applications generate "folder.jpg" when ripping CD audio. It's used to display album cover art. Could this auto-thumbnail functionality be written as a plugin?
I use amarok to manage my music (sorry to the Gnome people for all the nice tools you make in this regard but I really like Amarok!). I use Gnome primarily as my environement, but I would really like to see Nautilus support the ".directory" config file system that Konq supports (and the cover art script that copies the album cover art out of Amarok generates for you). I now have a bunch of folders on my file server that have a .folder.png file and a .directory file that tells any program that cares to parse it that the folder icon should be .folder.png. It would be really nice if Nautilus could support this as the current method of storing a user specific folder icon setting in $HOME/.nautilus/metafiles/file:%2F.....xml has many drawbacks IMO: 1. User specific (no easy way for a user to set a folder icon that other users can see). 2. Non mount path agnostic (e.g. Removable media like my iRiver may be mounted in different paths and there for the metafile icon setting may be ignored if mount paths change). 3. You can't copy the data and take the icons with you using arbitrary tools (like rsync). Nautilus may be able to copy the metadata prefs as it copies the files but this means users must always use Nautilus for everything if they want the metadata to go with it. 4. Networks shares do not have a global metadata db (similar to point 1 but more obvious in multi-machine, multi-user environments) and thus cannot set e.g. a folder icon on a network share and expect everyone to see it. I would love to see Nautilus supporting .directory file specification. If it would be possible as a plugin, please let me know and I'll see if I can look at it at some point.
*** Bug 325372 has been marked as a duplicate of this bug. ***
*** Bug 454147 has been marked as a duplicate of this bug. ***
Thumbnails on folders must not look bad. Take a look at http://www.flickr.com/photos/njpatel/2124789889/in/set-72157603637351266/
*** Bug 561152 has been marked as a duplicate of this bug. ***
Is this really a problem of nautilus? Looking at the code it seems better to fix this in gio. g_file_info_get_icon () or g_file_info_get_attribute_byte_string (info, G_FILE_ATTRIBUTE_THUMBNAIL_PATH) . I'd like to give it a try once we figure out HOW to do it.
Matthew Lambie: "Could this auto-thumbnail functionality be written as a plugin?" Yes, i wrote it: http://software.flogisoft.com/cover-thumbnailer/
It's worth noting that ID3 (and probably some of the other tag formats) also support embedded artwork inside of the files directly. It would be nice if that could be used for providing thumbnails for the individual audio files and the folders they are contained within. Embedded artwork saves having a whole load of album.jpg files cluttering everything up and also ensures that the back cover isn't chosen by accident. Many audio players use that artwork such as RhythmBox, the Music player in Android, iPod/iPhones. (although it does mean some space wastage as the cover is stored in each mp3 file, but not a whole lot). I did have a separate bug for embedded artwork for file thumbnails (as opposed to folders) that but it was merged with this one despite being somewhat different. https://bugzilla.gnome.org/show_bug.cgi?id=454147 I just had a go with cover-thumbnailer but it seems to be ignoring my music folder (perhapses because it's on a remote share, although it is mounted via fstab not gnome-vfs but maybe it's smart enough to tell now). And making covers for every folder in my home directory (most of which are blank cds).
@H3g3m0n: "I just had a go with cover-thumbnailer but it seems to be ignoring my music folder (perhapses because it's on a remote share, although it is mounted via fstab not gnome-vfs but maybe it's smart enough to tell now)." Go in System → Preferences → Cover Thumbnailer and add the path of your music folder "And making covers for every folder in my home directory (most of which are blank cds)." It's due to a misconfiguration of GNOME's folders. You can unckeck the "Uses GNOME folders" option in the preferences. I'm working on the next version of Cover Thumbnail and it will prevents from misconfiguration.
With cover-thumbnailer, we no longer need this task, since it was unlikely we were actually going to include this kind of thumbnailing in Nautilus. Please ask your distro to package and ship the plugin if you require album thumbnails.