If I select to show images resolution by: View -> Additional Information -> Image -> Image Size then why dolphin tries to show resolution for all of file, but not only for images. So I have "-" under folder and other files, which is not images. Reproducible: Always Actual Results: Why Dolphin can't detect mime-type of file and only then tries to show resolution or any other information?
Thanks for the report. Would you prefer to have nothing shown in the "Image Size" column for non-image files (rather than "-")? That probably makes sense.
Yep. But mostly it's looks weird in Icon Mode View. Where I get additional line only with "-". PS: of course this wish not only for images resolution, but for any of additional info that Dolphin can show (Lines count only for docs and Audio tags only for music). Thanks.
Resetting assignee to default as per bug #305719
Can we mark 301782 then as a duplicate as here is where the action happens :)
*** Bug 301782 has been marked as a duplicate of this bug. ***
Git commit 20b0cb68bf5cc1099fd6e61982817d9e2ae0130c by Frank Reininghaus. Committed on 06/09/2012 at 07:51. Pushed by freininghaus into branch 'master'. Do not show '-' for additional info which is not available for an item Thanks to Todd Jennings for the patch! REVIEW: 106304 M +25 -3 dolphin/src/kitemviews/kstandarditemlistwidget.cpp M +0 -7 dolphin/src/kitemviews/private/knepomukrolesprovider.cpp http://commits.kde.org/kde-baseapps/20b0cb68bf5cc1099fd6e61982817d9e2ae0130c
Git commit f64a82bd69bcc0f35c9024a8d43e486997b860dd by Frank Reininghaus. Committed on 06/09/2012 at 07:51. Pushed by freininghaus into branch 'KDE/4.9'. Do not show '-' for additional info which is not available for an item I'm only backporting the removal of the '-', not the update for the line number calculation in Icons View, because this is the safest part of the patch and also the one that fixes the most annoying part of the bug. Thanks to Todd Jennings for the patch! REVIEW: 106304 (cherry picked from commit 20b0cb68bf5cc1099fd6e61982817d9e2ae0130c) M +0 -7 dolphin/src/kitemviews/private/knepomukrolesprovider.cpp http://commits.kde.org/kde-baseapps/f64a82bd69bcc0f35c9024a8d43e486997b860dd
Sorry, reopened again by accident.
I've been testing it with current master. (thanks for fixing this btw :-) ) I like this new behavior much more than before. However, when one enters the directory there is a weird resizing of icons/thumbnails (actually it is animation? ). This is not something really obtrusive for me without nepomuk, but with it turned on, this resizing takes some more time, and i'm not sure users will like it.
Thanks Hrvoje for testing this and for providing feedback! I'm currently unable to test this myself, but I would assume that the cause of the problem you notice in master is the following: 1. When entering the directory, the information from Nepomuk has not arrived yet. Therefore, the lines which are actually reserved for this info are empty (this happens both in KDE/4.9 and master after the recent commits), and in master, these lines are not taken into account for the size calculation of the items. 2. As soon as the info from Nepomuk arrives, it is shown in the view. Now the items need more space in the view, and the size calculation has to be updated. This could cause the items to jump around. Does this analysis of the weird problem you noticed look reasonable to you? If yes, we should probably revert the master commit and just use the one from KDE/4.9. This would mean that empty lines are shown for information that is not available for an item. If there are many items for which some specific info (like the image size) is unavailable, this would lead to much white space being shown in the view, but I can't see any other way to fix this...
(In reply to comment #10) > Does this analysis of the weird problem you noticed look reasonable to you? Yes, it does. I do have a question though. This new behaviour is also shown with nepomuk turned off, and the user has chosen to show aditional information available without it (eg 'Type'). Would this use-case also be covered with your explanation? > If yes, we should probably revert the master commit and just use the one > from KDE/4.9. This would mean that empty lines are shown for information > that is not available for an item. If there are many items for which some > specific info (like the image size) is unavailable, this would lead to much > white space being shown in the view, but I can't see any other way to fix > this... I don't know how this looks with 4.9, but if i understand correctly, it doesn't show an "-", but it would show an empty space?
Thanks for the quick reply. (In reply to comment #11) > (In reply to comment #10) > > Does this analysis of the weird problem you noticed look reasonable to you? > Yes, it does. I do have a question though. This new behaviour is also shown > with nepomuk turned off, and the user has chosen to show aditional > information available without it (eg 'Type'). Would this use-case also be > covered with your explanation? Yes, it could also happen if Nepomuk is turned off because there are also other file properties which are loaded asynchronously (in particular, the number of items in subfolders). > > If yes, we should probably revert the master commit and just use the one > > from KDE/4.9. This would mean that empty lines are shown for information > > that is not available for an item. If there are many items for which some > > specific info (like the image size) is unavailable, this would lead to much > > white space being shown in the view, but I can't see any other way to fix > > this... > I don't know how this looks with 4.9, but if i understand correctly, it > doesn't show an "-", but it would show an empty space? Yes, exactly.
(In reply to comment #12) > Yes, it could also happen if Nepomuk is turned off because there are also > other file properties which are loaded asynchronously (in particular, the > number of items in subfolders). OK then ;-) > > Yes, exactly. Then that would be fine by me :-) I guess this should be leaved for some time so other users, and you off course, can test current behaviour/provide feedback, and see have i interpreted this correctly?
Thanks for the quick reply! I was busy with other things in the meantime, but I'm going to commit the change in a minute.
Git commit 99ec9ecc336b5ae6109bace39ae8383664295b7c by Frank Reininghaus. Committed on 24/09/2012 at 23:32. Pushed by freininghaus into branch 'master'. Revert part of 20b0cb68bf5cc1099fd6e61982817d9e2ae0130c That commit, which disregarded roles with empty text for the row number calculation in Icons View, caused the problem that icons might jump around while information was retrieved asynchronously because previously empty roles could get a non-empty value, and the corresponding items would need an additional row in the view. Thanks to Hrvoje Senjan for testing this feature in master and reporting this issue early, such that we could fix it quickly and prevent that other users suffer from this bug! M +3 -25 dolphin/src/kitemviews/kstandarditemlistwidget.cpp http://commits.kde.org/kde-baseapps/99ec9ecc336b5ae6109bace39ae8383664295b7c
Many thanks for fixing this bug. Now it work like i want it, but now items has a strange empty lines, which is looks slightly ugly. Here is example with "Size", "Image Size" and "Line Count" are selected: http://storage9.static.itmages.com/i/12/1004/h_1349355550_2985885_947d25b9b2.png
(In reply to comment #16) > Now it work like i want it, but now items has a strange empty lines, which > is looks slightly ugly. Yes, we know about that. We tried to remove the empty lines, but this caused other problems, see comment 9 and the following comments.
razrfalcon, here's behaviour described in comment 9: https://vimeo.com/50773840 For some reason speed of the video is at least two times the real time
I really like this behaviour. Looks pretty. =)