They are scaled probably, but I think they should not. Reproducible: Always Steps to Reproduce: 1. Select "Icons" in Dolphin Preferences -> View Modes 2. Select Default "48" and preview "64" 3. Select Width "Small" and Maximum lines "2" 4. Look at icon view view. Actual Results: Some icons look blurry. Those which are with 2 lines of text. Expected Results: Icons are not scaled and not look blurry.
Looks like a Qt bug. For some QTextLine.height() I get 17 (which is the same as fontHeight or lineSpacing), while for others it returns 18, making a two-line text two pixels higher.
Thanks for the bug report and for the analysis! I cannot reproduce, but it might depend on the font. Maybe this is related to bug 308022.
Hm, I guess we might be able to work around the problem. In DolphinItemListView::updateGridSize(), we set the height of KItemListStyleOption::maxTextSize to option.fontMetrics.lineSpacing() * "number of lines". The height that is reserved in the view for an item, calculated in KStandardItemListWidgetInformant::itemSizeHint(), is limited by this height. Later on, in KStandardItemListWidget::updateIconsLayoutTextCache(), we calculate the number of lines by dividing this height by the line spacing again, and then simply layout this number of lines without caring about option.maxTextSize.height() any more. The actual height of these lines (and thus also the total height of the item) might then be larger than the height that the item pretends to have according to KStandardItemListWidgetInformant::itemSizeHint(). I'm not a graphics expert, but I guess that the blurring is caused by trying to squeeze the item, which is one pixel higher than it should be, into the space that is reserved for it. Maybe this could be fixed by introducing a member "maxTextLines" in KItemListStyleOption, and using this in KStandardItemListWidgetInformant::itemSizeHint() to calculate the *real* height of the text. The view would then reserve one more pixel for the item.
*** Bug 308022 has been marked as a duplicate of this bug. ***
There is a patch at https://git.reviewboard.kde.org/r/113871/ that might fix, or work around, the problem, but I'm not sure because I cannot reproduce the bug. It would be very helpful if anyone who can reproduce it and builds Dolphin from source could try it!
Git commit 70cfa627e5a402f209c2eb1f3cfbc839d61740ad by Frank Reininghaus. Committed on 24/02/2014 at 20:05. Pushed by freininghaus into branch 'master'. Make the handling of the "maximum text lines" setting more robust If the user sets a maximum number of text lines in the settings, this number was translated into a maximum height in pixels using QFontMetrics::lineSpacing() before this commit. In KStandardItemListWidgetInformant::itemSizeHint(), this maximum height limited the size that is reserved for the item. However, in KStandardItemListWidget::updateIconsLayoutTextCache(), the maximum height was translated back into a maximum number of lines, which limits the number of lines that are created using the QTextLayout. This approach could lead to problems if the real height of the layouted text is 1 pixel more or less than QFontMetrics::lineSpacing() times "number of lines". Now we do not store a "maximum height" inside the "maximum size" explicitly, but store a maximum number of lines and a maximum with (for Compact View) separately, and then use the number of lines also to calculate the required size in KStandardItemListWidgetInformant::itemSizeHint(). This should make sure that the correct height is reserved for each item. Thanks to Christoph Feck and Emmanuel Pescosta for helping to debug this problem and testing the patch. FIXED-IN: 4.13 REVIEW: 113871 M +4 -2 dolphin/src/kitemviews/kitemliststyleoption.cpp M +2 -1 dolphin/src/kitemviews/kitemliststyleoption.h M +2 -1 dolphin/src/kitemviews/kitemlistview.cpp M +9 -10 dolphin/src/kitemviews/kstandarditemlistwidget.cpp M +6 -11 dolphin/src/views/dolphinitemlistview.cpp http://commits.kde.org/kde-baseapps/70cfa627e5a402f209c2eb1f3cfbc839d61740ad
I checked it on on recent master built against ubuntu 13.10 dev packages (qt4.8.4). Looks ok. http://3.imgland.net/mrvh2e.png
That's good to know. Thanks for testing it!