Version: 1.0.0-beta5 (using KDE 4.3.1) Installed from: Ubuntu Packages In Configure->Album View->Icon-View Options there is no option to show the type of the image. Since many different version of the same image can be present it could comfortable to allow the user to visually select the right one without being forced to click on it and to look at the image name.
I'm totally agre with this. Other application use a small icon set on a corner of thumbnail, with mime type ("raw", "jpg", "tif", "png", etc...) As icon-view Qt4 model view port is done, this can be studied as well now... Gilles Caulier
See also https://bugs.kde.org/show_bug.cgi?id=148223
Implemented in 2.0.0 : http://www.flickr.com/photos/digikam/5516625907/sizes/o/in/photostream/ Gilles Caulier
Git commit 6173a3635952f343474898eb3706dbce63dc7fd7 by Gilles Caulier. Committed on 11/03/2011 at 12:31. Pushed by cgilles into branch 'master'. new feature : print item file format over icon view item as Lightroom and Aperture See this screenshot for details : http://www.flickr.com/photos/digikam/5516625907/sizes/o/in/photostream/ BUGS: 268098 BUGS: 148223 BUGS: 208504 M +17 -14 digikam/items/digikamimagedelegate.cpp M +1 -1 digikam/items/digikamimagedelegate.h M +3 -4 digikam/items/digikamimagedelegatepriv.h M +9 -2 digikam/items/imagedelegate.cpp M +5 -3 digikam/items/imagedelegatepriv.h M +16 -27 digikam/items/imagethumbnaildelegate.cpp M +3 -2 digikam/items/imagethumbnaildelegate.h A +66 -0 digikam/items/imagethumbnaildelegatepriv.h [License: GPL (v2+)] M +72 -51 digikam/utils/albumsettings.cpp M +3 -0 digikam/utils/albumsettings.h M +28 -0 libs/widgets/common/itemviewimagedelegate.cpp M +1 -0 libs/widgets/common/itemviewimagedelegate.h M +20 -12 utilities/setup/setupalbumview.cpp M +2 -3 utilities/setup/setupalbumview.h http://commits.kde.org/digikam/6173a3635952f343474898eb3706dbce63dc7fd7
Do we really need to default to "Yes" for this option? That would mean that the majority of users will want this switched on.
I would also prefer a default set to "off". And, to have a consistent look, I would propose to align this icon with the icon item border, not the thumbnail border.
Marcel, Andi, I turned on by default to test it and give users feedback. If you find this option too intrusive, i can turn off by default... Andi, where do you want to place this mark exactly. There is no free place to host this mark without to be over thumb. Try vertical thumbs, and different size. Mockup suggestions are welcome. Gilles Caulier
I thought of something like this: http://www.flickr.com/photos/26732399@N05/sets/72157626121077651/ But right now I'm not sure if it doesn't look even worse :-)
Andi, I already tried your proposal, and i haven't be convinced by this way. Graphically, it's not perfect, not homogeneous. On this entry : https://bugs.kde.org/show_bug.cgi?id=268098#c18 ...an user post a proposal. I'm not convinced too. It's not elegant. Also, we have a problem with thumbbar (preview mode, editor, and later LT), where no information is displayed under thumb, excepted rating. How i can add file format info without to add a new line in thumbbar, which will increase space consuming. I studied a way to use filename line under thumb, to display both info : - filename (without extension) - file format (highlighted using same graphic way than currently under thumb) In setup, both can be enable separately, as now. The line under thumb can be show these information : Only filename : dsc123456 Filename + format: dsc123456 JPG Format only : JPG There is no problem with icon view using this solution, but with thumbbar, the new line must be displayed under thumb. This solution has the advantage to not show format information under thumb of course. Your viewpoint please... Gilles Caulier
Hi Gilles You have reason, my last proposal was not elegant and even more complex to code. I'm not a photography professinal, just average, but works in raw as them. We liked too much DarkTable solution, but DigiKam has much more options and flexibility to show info, so I like your proposal. In fact, this time I send (will try, always make mistake on attaching files :( ) a capture of my own config and tried to not use not used space to show file format. In file "Tag 1" is similar to your proposal, but in "Tag 2" we have a lot of wasted space that will show format more clear, I think. What do you think. THANK YOU GILLES
Created attachment 57901 [details] Example 1 - Format tag next to file name
Created attachment 57902 [details] Example 2 - Format tag next to file size (more clear, I think)
I like the second version...
Created attachment 58031 [details] patch to print item format outside thumb area I think that none of both can be fine as well for the future. The reason is about this entry : https://bugs.kde.org/show_bug.cgi?id=148572 ... and especially the way to print image file name behind thumbbar item, as with icon view. In Thumbbar, use currently icon-view model-view implementation (not yet in LT, but it just a question of time) The goal is to be able to print information under thummbar : Rating, filename, and format. The patch attached implement format printing outside thumb area : 1/ In icon-view, print format on the right side of image file name if both are displayed (in this case, file name is without extension). 2/ If file name is not display, only format is displayed instead file name. 3/ In thumbbar (preview mode), this patch try to display file name and/or format behind thumb. This point do not work yet. Please take a look... Gilles Caulier
Created attachment 58033 [details] icon view screenshot with patch #58031 applied. Case 1
Created attachment 58035 [details] icon view screenshot with patch #58031 applied. Case 2
Created attachment 58037 [details] icon view screenshot with patch #58031 applied. Case 3
Marcel, Can you take a look to my patch please ? Look my comment from #14... Gilles Caulier
Hi again I really continue thinking why not could be "Show file size and format" togheter ... there is enough space to fit both of them!!! Thank you
finstrodela...: Not everyone has the size enabled. There is a very large number of possible combinations. Gilles: I see several problems with this patch: - the large, black item with bold letters and sharp corners is very dominating, and I dont like it aesthetically: http://wstaw.org/m/2011/03/19/plasma-desktopd25183.jpg - it collides with the group indicator (which is itself no optimal and has no better place atm): http://wstaw.org/m/2011/03/19/plasma-desktopo25183.jpg - In the thumbnail bar, the filename is cut: http://wstaw.org/m/2011/03/19/plasma-desktopu25183.jpg I assume a problem in the drawName method, where bRect's width is set. Both text dont really now of each other; the format is drawn at a fixed position, and the name in the center. The name should be drawn offset to the left. - Compare the current unpatched version: You see that the filename's font is much smaller. Is it reset to larger size somewhere? - the thumbnail bar is now wasting space, if the name is not displayed but the rating: http://wstaw.org/m/2011/03/19/plasma-desktopp25183.jpg Previously, it was more compact, although sometimes a nuisance to click on the rating. So this has pros and cons. I'm not quite sure either how to do this best. I like the second mockup above; but it's done for a specific set of options, and with 8 options we are at 256 different combinations. In addition to that, thumbnail size differs, and the situation is so much different for 64px thumbs than for 160px. I agree to combine format + filename if both are selected, seems to make sense. Especially if the suffix is cut if the format is displayed as well. I would suggest using the smaller font for the filename like for all other fields. There are already so many options, but I have a feeling that the thumbbar needs different settings than the main icon view. You can have large thumbnails and tiny thumbs in the thumbbar. You may want everything displayed in the icon view, and nothing in the thumbbar. Very difficult to get it all right.
Marcel, I will left this patch as well and lets current implementation with type mime over thumbnail. I think it's enough (see comment #4 for details). But we will need to review icon view contents to be more suitable. For ex, there is a problem between rating and grouped icon which are not plugged at the right place in icon view item (see bug 275381) Gilles Caulier