Improvements to file browser thumbnails

[Beep6581]

Originally reported on Google Code with ID 1255

The file browser's thumbnails often look very basic and and poorly implemented when an album has photos of mixed width and height ratios.

Take this screenshot as an example: http://i.imgur.com/a3WgQ.jpg Just because one photo is wide, the rest of the album suffers and RT fits only one small thumbnail per row. http://i.imgur.com/PvGi3.png I can't see the filename of the smaller photos even though there is more than enough room to fit it. The overlay buttons for each thumbnail appear far away from the thumbnail.

Feature request to better handle thumbnails of various dimension ratios - to not contain small thumbnails in ridiculously large boxes, to display as much of the filename as possible, to display more info in the tooltip (file size, more metadata, what postprocessing profile is being used if the name is known [this one after xmp integration?])

Mockups: http://www.rawtherapee.com/images/mockups/file%20browser%20thumbnails%201.jpg http://www.rawtherapee.com/images/mockups/file%20browser%20thumbnails%202.jpg

Reported by entertheyoni on 2012-02-17 02:02:10

[Beep6581]

I 200% agree with you! I like your mockup #1 more, but i think that we should add a white inner framing and remove the outer "selected" framing. Selected image would turn it's white inner framing to red or any other selection color. The drop shadow looks nice :)

It would be nicer if the image's information below were better associated to the image by displaying them as a white strip (well, the same color as the border or a lighter one?) with a 1 pixel spacing between this strip and the thumb.

Reported by natureh.510 on 2012-02-18 19:38:27

[Beep6581]

Glad you agree :] These mockups are just to show what could be, they're not my preferable final proposals in any way.

I dont like the outline in #2, but I do like the tooltip. I like how compact #1 is. Instead of outlines we could use solid frames. Outlines or frames might be nicer with rounded corners, rounding value taken from gtkrc. Its very important to me to see the whole filename, would be great if it could be optionally set to wrap instead of clip. Some elements dont need to always be visible, they could only be showed on hover, e.g.delete and send to queue buttons. Metadata such as resolution can be showed over the image as it is now in RT, or under the thumbnail (my preference). Space should be used optimally, e.g. notice how much space is left in the line containing the image resolution in both screenshots.

Reported by entertheyoni on 2012-02-19 08:44:30

[Beep6581]

I like your strip idea. The color could be taken from an existing color in gtkrc, one that contrasts with the canvas background color over which thumbs are drawn, perhaps with an alpha 50, or perhaps not :]

Reported by entertheyoni on 2012-02-19 08:49:46

[Beep6581]

DrSlony, are these mockups available as a patch?

Reported by michaelezra000 on 2012-03-18 21:10:43

[Beep6581]

No Michael.

Reported by entertheyoni on 2012-03-19 16:18:33

[Beep6581]

Issue 785 has been merged into this issue.

Reported by entertheyoni on 2012-05-09 21:19:47

[Beep6581]

I pretty much view #1 as being perfect (with the addition of tooltips from #2). I think adding the strips

I dont like the outline in #2, but I do like the tooltip.

Yea, I dislike the outline. It just looks like its floating there by itself. Also, it has too much padding. I prefer the outline to be directly hugging the image, like

1.

Its very important to me to see the whole filename, would be great if it could be optionally set to wrap instead of clip.

An option to wrap, and maybe an option to set the maximum number of lines.

Metadata such as resolution can be showed over the image as it is now in RT, or under the thumbnail (my preference).

An option to show any information on as many lines necessary, but default to what you have in #1.

Regarding the strip idea, I don't know if I'd like the look of a strip, but I'm worried that a tiny 3px border would be hard to spot if you left the computer and came back after lunch break or something. Maybe the border should be brighter? Or yellow?

Reported by sankeytms on 2012-05-09 22:14:04

[Beep6581]

Issue 533 has been merged into this issue.

Reported by entertheyoni on 2012-08-21 21:15:32

[Beep6581]

Issue 659 has been merged into this issue.

Reported by entertheyoni on 2012-08-21 21:16:03

[Beep6581]

Issue 1505 has been merged into this issue.

Reported by entertheyoni on 2012-08-21 21:16:23

[Beep6581]

From issue 1509:

Possible solutions:

1. Fixed height, flexible width containers All thumbnails are the same height. Portraits are narrower, panoramas may occupy a much wider space. Just like words in a line. This would give an aesthetically pleasing overall look, but may be less efficient during the loading of thumbs.

2.1. Square containers Every container is the same size, thumbnails are squeezed into them (longer side fits). Easy to handle, fast(er?) to load, but panoramas may be a problem.

2.2.Square containers with cropped thumbnails Similar to 2.1, but thumbnails do not show the whole original image, but only some part of it. Solves the problem of panoramas squeezed into fix squares, but most probably needs more processing during thumbnail generation.

The suggestions are in the order of my personal preference.

Reported by gyurko.david@e-arc.hu on 2012-08-25 08:57:16

[Beep6581]

I'm strongly against 2.2. Its fine for web galleries but not for RT.

Reported by entertheyoni on 2012-08-25 16:24:20

[Beep6581]

I also have the habit to keep my panoramas in the same folder with my RAW files and this issue bothers me sometimes. I think that option "1. Fixed height, flexible width containers" seems the way to go as it doesn't do any nasty cropping and leaves the viewer recognize the images easily by their thumbnails.

Reported by philipp.lutz.g on 2013-03-17 22:55:31

[Beep6581]

Solution 1: Ok for a fixed height, but I think that thumbnails should have a minimal and maximal width.

Then we could get rid of the grid organization in favor of a "flowing distribution". It means that each row can have a variable number of thumbs. To have a fancy and clean display, the thumbnail container's width should be calculated after computation of the distribution, so each row will fill the available space by adding padding space in the thumbnails (am i clear here? :) ).

Solution 2: let's have a squared shape for the thumbnail container. For a given camera, the scale factor would be the same for portrait and landscape images, while actually the landscape images are bigger than the portrait one (considering the fixed height).

Reported by natureh.510 on 2013-03-17 23:55:07

[Beep6581]

Isn't this the cleanest approach: http://www.rawtherapee.com/images/mockups/file%20browser%20thumbnails%202.jpg

Reported by michaelezra000 on 2013-03-18 01:06:57

[Beep6581]

I prefer fixed height, gives a more consistent look and better examination of wide thumbnails too.

Reported by gyurko.david@e-arc.hu on 2013-03-18 07:00:11

[Beep6581]

Solution 1 from comment 15 sounds good to me as long as they also have said max width. My initial reaction was "no!" as I've seen this before somewhere and it looked horrible, but considering RT will show mostly files of the same aspect ratio, and that, unlike the implementation that I saw, this will have a max width value, it should look decent. Then again, I'm fine with fixed width and height too.

Would be nice if there was a tooltip with the info from (i) when you hover over a thumb, because I like to keep thumbs small and sometimes I'm forced to make them large just to see the (i) info which does not fit inside small thumbs.

As for too-long filenames, chopping off extra characters is good, but instead truncating the middle would be ideal, because the end is likely to contain a number differentiating that image from similar others, e.g.

         |                           |
         |                           |
         -----------------------------
2013-03-19 BW church tenerife tone mapped 1.tif

         |                           |
         |                           |
         -----------------------------
         2013-03-19 BW... mapped 1.tif

Reported by entertheyoni on 2013-03-19 00:05:10

[Beep6581]

I would very much like to implement tooltips with elaborate information about the selected file. I am curious how to add a table to a tooltip as in http://www.rawtherapee.com/images/mockups/file%20browser%20thumbnails%202.jpg Can this be an HTML table?

Reported by michaelezra000 on 2013-04-06 22:54:32

[Beep6581]

It can easilly p*ss off users, like me, so it'll have to be optional. The simplest way is to enable it altogether the filenames' strip, thanks to the "i" button i guess.

For the content of the widget, you'll have to create an elaborated widget that you should be able to include in the tooltip.

Reported by natureh.510 on 2013-04-06 22:59:36

[Beep6581]

Request by Elle Stone for no-thumbs mode, filenames only. http://rawtherapee.com/forum/viewtopic.php?p=35389#p35389

Reported by entertheyoni on 2014-01-27 17:14:25

[da-phil]

@Beep6581 @heckflosse @Floessie I guess we can continue the discussion here, sorry for not finding the old issue at first @Beep6581! actually I'm happy with either mockup, as long as panoramas don't take up all the horizontal space as in my example screenshot.

[Hombre57]

I think we should postpone this issue until the Gtk3 branch becomes master. We already have too much GUI stuff going on (including the softproofing branch and the color picker patch), and the Gtk3 must be hard to maintain (looking at @Beep6581 here, since he's the maintainer).

Be definitely something to put on top of the TODO list right after.

[heckflosse]

:+1: for solving this issue after gtk3 branch becomes master! :+1: also for put it on top of the TODO list then

[Beep6581]

Agreed. Also, I would wait for the next stable Gtk+ version after 3.20. The reason is that 3.20 was planned a long time ago to break things, and it has. I read some things about the post-3.20 release plan some months ago which sounded crazy - I'll have to get an update on that first.

[da-phil]

oh, that sounds reasonable to finish work on the gtk3 branch first. :+1: also for putting it on top of the TODO list for post gtk3 work!

[maxbelloni]

Hello,

First post (just come to adopt RawTherapee, which is a very interesting - aka masterpiece - software)

I agree that the "forced" single column is ugly and little productive. The possibility of choose a fixed number of columns should be implemented, mainly because that screen is useful to quickly identifying the image to be processed: more image are shown, faster is the choice.

Hope this helps!

Max