At the normal zoom level, the thumbnails should be the same size as they would be at the maximum zoom level.
I don't understand this bug. Are you talking about the icon canvas behaviour in Nautilus? If so, that's not what we want in Thunar (actually I think the Nautilus behaviour is a bug).
The thumbnails that generated for videos and images are too small. I can hardly even see them. I have to zoom in all the way to make out the thumbnail.
The generated thumbnails should be at max. 128x128, otherwise its a bug in the generator. Concerning the display, thumbnails are displayed at the zoom level selected by the user. In fact, this means that you may need to zoom in to 128x128 to actually make use of some thumbnails (even at that level certain thumbnails will be useless). Thumbnails serve to give a better idea of the content than the file name (tho, good file names are still the best way to distinguish files) in the file manager (following the user's choice for the zoom level). The behavior in Nautilus was found to be inconsistent and not very user-friendly during the design stage of Thunar, because the icon canvas doesn't follow the user's zoom level choice, but thumbnails are larger than other file icons, which makes it harder for humans to discover items than an icon view that uses equally sized icons (avoiding to scale up, of course). Because of this (and the horrible speed of Nautilus icon canvas when displaying folders with many pics, tho that's less important than the ease-of-use argument), we always use the user selected zoom level for all items in the views (scaling up/down is easy enough if you really need to see more detail temporarily). The icon view in Thunar doesn't yet use all available space for thumbnails. Most of the time a few pixels are wasted due to the way the view<->renderer interaction works. There's an open bug #1266 for this, which will hopefully be fixed for the final version.
Moving to 0.3.2beta2.
How about letting the user decide? You could add an option into the settings dialog in which the user could set which dimensions for thumbnails he wants, independent of the actual icon size.
Hm, dunno, have to think about this again.
Moving to 1.0.0final.
(In reply to comment #5) > How about letting the user decide? > > You could add an option into the settings dialog in which the user could set > which dimensions for thumbnails he wants, independent of the actual icon size. > I don't think thumbnails exist to allow you to read the files. They are just a means of making each icon unique so as to appeal to the user's visual memory. For example with a PDF document, you can see the general shape of it: is the first page blank, is it a title and abstract, is it a report with two columns, or one column, is there some colour in it? I remember reading a study showing that this can slightly improve the user's ability to quickly select files (so long as there are not far too many PDF files in the one directory). As for making bigger thumbnails, the standard allows for the 256x256 size. You could have a popup hint when the mouse hovers over a file (I think Konqueror does this) which shows a larger thumbnail?
(In reply to comment #8) > (In reply to comment #5) > > How about letting the user decide? > > > > You could add an option into the settings dialog in which the user could set > > which dimensions for thumbnails he wants, independent of the actual icon size. > > > > I don't think thumbnails exist to allow you to read the files. They are just a > means of making each icon unique so as to appeal to the user's visual memory. I agree. But if they’re too small so that you cannot recognize the content, they are pretty much useless. I for myself now got used to fire up Gthumb instinctively if I want to browse a directory containing images since Thunar’s thumbnails aren’t really useful here. > As for making bigger thumbnails, the standard allows for the 256x256 size. You > could have a popup hint when the mouse hovers over a file (I think Konqueror > does this) which shows a larger thumbnail? Nice idea. But I also don’t want Thunar to become slower because of this. But if it’s implemented in a reasonable way, I’m all for it.
I've been thinking a little more about this. Another possible solution would be to zoom part of the image... that is for a 1024x768 image only generate a thumbnail for the top quarter of it. This has its own problems though - especially with images which have a large blue sky for example. I think popups with larger thumbnails would be good. Also, a lot of windows users seem to like the "View as Slideshow" option to browse through images - it might be a good idea to have a compile-time configure flag, which adds a slideshow feature (perhaps using ristretto since it is lightweight enough and also handles large thumbnails).
I recently used Nautilus in a Hardy Ubuntu desktop. I can see a certain advantage in having larger thumbnails, but the implementation in Nautilus is weird (as it forces it on you). In Thunar, currently when you increase the thumbnail size the size of folder thumbnails increases too. This is actually a bit annoying, as it wastes screen space and just seems odd. I think perhaps the user should have an option to make zooming of files and folders independent.
I'd like to throw in my 2¢. For office/business work I used KDE some time ago and after switching to fxce I really missed the option to make thunbnails bigger than the icons. My complete office is PDF based and my photo colletion is still file system based, so I also missed the "preview on hover" feature. Icon size is a matter of personal taste, interpretable thumbnails are a matter of usability. I think the user should have the option to define a "magnifying thumbnail factor" or complete independent size settings. Of course I'd also love to see the "preview on hover" feature, maybe with some EXIF info decorated :) (and some samplerate and ID3 info on sound files... tbc) Thanks for making this nice file manager even better!
(In reply to comment #12) > I'd like to throw in my 2¢. For office/business work I used KDE some time ago > and after switching to fxce I really missed the option to make thunbnails > bigger than the icons. I know what you mean, but it is difficult to provide an inconsistent interface and be consistent about it. I suggested before that the real problem is folder icons being too big... if you make a folder icon bigger it doesn't give me more information about what it is. It should be possible to have them stay small while you increase the size of the other icons. You might argue the same is true with file icons too, and you might be correct. I think the way Nautilus resizes the thumbnails is ugly though. Perhaps Thunar could allow icons to be smaller than thumbnails but only by a constant factor - i.e. "One thumbnail is the size of four icons" in order to keep the files in a grid. > My complete office is PDF based and my photo colletion > is still file system based, so I also missed the "preview on hover" feature. I too work with a lot of PDF (and PS and TEX files) as I am at University I would also like to see "previews on hover". I was even wondering about a sliding drawer which showed a larger thumbnail of the currently selected file, with some details (size, permissions, tracker-tags).
> Perhaps Thunar could allow icons to be smaller than thumbnails but only by a > constant factor - i.e. "One thumbnail is the size of four icons" in order to > keep the files in a grid. I agree, but the user should be able to define the factor. Maybe even floats, if she doesn't matter about consitent grid.
Imho, the best thing to do would be to let user choose different normal icon sizes and thumbnail sizes seperately like in Dolphin.
Here's a quick summary of how I think we can improve the thumbnail experience while maintaining full compatibility with the thumbnail spec: Thunar >= 1.1.0 uses the tumbler D-Bus service to generate thumbnails. We can easily make it request thumbnails either at 128x128 or at 256x256 pixels which are the only valid thumbnail sizes supported by the thumbnail spec. 256x256 pixels should be large enough for everyone. So I suggest we extend the zooming levels by a few additional steps and make it scale from 16 up to 256 pixels. We can then generate large (256x256px) thumbnails for all levels > 128 pixels and normal (128x128px) thumbnails for all levels <= 128 pixels. Generating large thumbnails burns more CPU cycles, so we could control the largest possible size with either a hidden setting or a configure switch. This is as far as I'd go with this. I'm absolutely not in favor of dropping compatibility with the thumbnail spec. So, how does this sound?
(In reply to comment #15) > Imho, the best thing to do would be to let user choose different normal icon > sizes and thumbnail sizes seperately like in Dolphin. +1 Different thumbnail sizes v. icon sizes is what could work best for Thunar since it remembers only one icon size for all directories. It's boring to switch zoom back and forth over time and I believe thumbnails to be the only case where people really want to zoom in. My 2 cents :)
https://bugzilla.gnome.org/show_bug.cgi?id=671004 - see examples in this bug, this is especially important for video files, especially those in the now very popular 16:9 aspect ratio. So I belive that the logic for thumbnails should be as follows - thumbnails should be a step larger than default icons (there is a point displaying content larger when we actually have content to show) and when the thumbnail is wide, then restrain its size only in the vertical dimension (until some limit that will only be really hit by weird things like panaramic photos, say use the same limit as for the text label max width). The default icon view on the default zoom level has plenty of space for 128px high video icons for 16:9 files.
Re Jassis' comment: "256x256 pixels should be large enough for everyone // the only valid thumbnail sizes supported by the thumbnail spec": is this still true 7 years on? I regularly rue the fact that I can't mousewheel zoom to have icons a little larger. If the thumbnail spec had changed then could Thunar allow larger thumbnail sizes? I figure the CPU cycles concern must be relatively unimportant now compared to 2010?
Unfortunately this is still an issue under Thunar 1.8.0, under Arch at least. I was hoping that the update/port to GTK3 would see thunar/tumblers small thumbnail issue fixed in the process as I thought one of the main reasons for the GTK3 update was to make thunar more usable for HiDPI users but sadly this hasn't happened and thumbnail previews are still way to small to be properly visible, certainly on 4K+ displays. I would cite caja's (the MATE file managers) code as a reference for how thumbnails should be handled in a GTK3 file manager because it lets you scale thumbnails much larger than Thunar does (much bigger than 128x128) but unfortunately caja currently has a bug that prevents it generating thumbnails for video files stored on samba shares so there is currently no perfect thumbnail generation under any Linux file manager.
I forgot to mention that Nemo and Nautilus both have the same problem with not being able to show thumbnails for videos on network drives that caja exhibits. That should be no surprise as they are all derived from nautilus. Thunar / tumbler currently only displays thumbnails for videos on network drives if you apply the accept-network-paths-in-ffmpeg-thumbnailer-plugin.patch from here: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/tumbler
@ Dan MacDonald Please take a try for thunar 1.8.2, it supports thumbnails up to 128px x 128px, works fine for me. For more details, check Thunar Bug #14451 128px x 128px currently is the maximum thumbnail size specified by Freedesktop.org (called "large") If you want more, I think the correct approach would be to first re-adjust the fd.org specification. I already opened a bug for that: https://bugs.freedesktop.org/show_bug.cgi?id=106939 IMO this bug can be closed now
Yes, from my POV the previews are large enough by now, thanks for taking care of this .
Great! Thanks for the feedback ! So I will close this bug now as a duplicate. Iif it should not work as expected, please file a new bug ! (this one is already a bit long) *** This bug has been marked as a duplicate of bug 14451 ***