Created attachment 177072 [details] Inconsistant link icon size SUMMARY In Dolphin, files that are links have on their preview a link icon, but this icon has a very inconsistent size depending on files. STEPS TO REPRODUCE 1. In dolphin, in one folder : create a link to a folder (drag and drop in it, link here). 2. In the same folder, create a links of multiple pictures. 3. See if the link symbol has different size depending on files/folders. OBSERVED RESULT The size of the link icon is inconsistent. EXPECTED RESULT Every link symbol should have the same size. I would prefer it to be something like as high as one line of text (of file name). SOFTWARE/OS VERSIONS Operating System: KDE neon 6.2 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.8.0-51-generic (64-bit) Graphics Platform: Wayland
You're absolutely right, and I never noticed it! This appears to be an issue of the icon thumbnailer code, as the link icons become the same size if I disable thumbnail previews, and I see the same issue on the Plasma desktop too. So it's not an issue specific to Dolphin.
Update, this bug is about overlay of thumbnail in general. Unauthorized access icon are affected. And for those who were searching the bug of inconsistency between zoom levels instead of between files, it is Bug 497372.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/154
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/886
Git commit fe56127d9e90c2b364189d38ea43c64ee2019874 by Méven Car. Committed on 11/01/2025 at 12:19. Pushed by meven into branch 'master'. Icons: when adding overlays pass in the output size Instead of the pixmap size that won't be accurate. It allow KGuiAddons::addOverlays to draw larger images to add overlays. Consequently the emblems are not longer dependant scaled based on the pixmap aspect ratio. M +3 -12 src/kitemviews/kfileitemmodelrolesupdater.cpp M +2 -3 src/panels/information/informationpanelcontent.cpp https://invent.kde.org/system/dolphin/-/commit/fe56127d9e90c2b364189d38ea43c64ee2019874
Git commit 50d44ab177f93ca3acd372f492f4fc3b1015286e by Méven Car. Committed on 11/01/2025 at 13:26. Pushed by meven into branch 'release/24.12'. Icons: when adding overlays pass in the output size Instead of the pixmap size that won't be accurate. It allow KGuiAddons::addOverlays to draw larger images to add overlays. Consequently the emblems are not longer dependant scaled based on the pixmap aspect ratio. (cherry picked from commit fe56127d9e90c2b364189d38ea43c64ee2019874) M +3 -12 src/kitemviews/kfileitemmodelrolesupdater.cpp M +2 -3 src/panels/information/informationpanelcontent.cpp https://invent.kde.org/system/dolphin/-/commit/50d44ab177f93ca3acd372f492f4fc3b1015286e
Git commit 523f909fc3c92e56374219f27b0a332271c59961 by Méven Car. Committed on 13/01/2025 at 17:12. Pushed by meven into branch 'master'. KIconUtils: take into account dpi for overlays M +8 -8 autotests/kiconutilstest.cpp M +18 -10 src/util/kiconutils.cpp https://invent.kde.org/frameworks/kguiaddons/-/commit/523f909fc3c92e56374219f27b0a332271c59961
I think the commit is a good step, but does not yet fix the issue: Built with the latest master (and [!164](https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/164) reverted), the overlays still have different sizes for different preview formats.
Created attachment 177831 [details] Inconsistent icons sizes after patch
(In reply to Thomas Moerschell from comment #9) > Created attachment 177831 [details] > Inconsistent icons sizes after patch This might require a master dolphin and https://invent.kde.org/system/dolphin/-/merge_requests/889 to be in effect.
Created attachment 177851 [details] Situation on desktop built from master You're right, dolphin from master is fine. However, the situation on desktop (also built from master) is still broken.
(In reply to Thomas Moerschell from comment #11) > Created attachment 177851 [details] > Situation on desktop built from master > > You're right, dolphin from master is fine. However, the situation on desktop > (also built from master) is still broken. You are correct. Please open a new bug for plasma-desktop. Some of what https://invent.kde.org/system/dolphin/-/merge_requests/889 will be needed (enlarge the icon size to maximum available size instead of the source image size scaled).
(In reply to Méven from comment #12) > (In reply to Thomas Moerschell from comment #11) > > Created attachment 177851 [details] > > Situation on desktop built from master > > > > You're right, dolphin from master is fine. However, the situation on desktop > > (also built from master) is still broken. > > You are correct. Please open a new bug for plasma-desktop. > This seems like a pre-existing issue in plasma before the MR in kiconutils, I can reproduce it in Plasma 6.2.5 with Framework 6.10.
*** Bug 499766 has been marked as a duplicate of this bug. ***
*** Bug 499907 has been marked as a duplicate of this bug. ***
*** Bug 499866 has been marked as a duplicate of this bug. ***
Is this bug what is causing this strange preview behaviour on Nextcloud folders? https://github.com/nextcloud/desktop/issues/7871 Present since Updating to Dolphin 24.12.2 but it's fine with 24.12.1. Thanks!
(In reply to Gauthier from comment #17) > Is this bug what is causing this strange preview behaviour on Nextcloud > folders? https://github.com/nextcloud/desktop/issues/7871 > > Present since Updating to Dolphin 24.12.2 but it's fine with 24.12.1. > > Thanks! Yes, also I confirm that reverting to Dolphin 24.12.1 fixes the problem.
Installed dolphin from GIT, i confirm that the bug is solved.
When can we expect this to be in a tagged release? broadly guessing from git history it seems there was about a month between `24.12.0`, `24.12.1` and `24.12.2`, so can we expect this to land in a `24.12.3` in early march? Or is this just a coincidence and we might get it earlier?
(In reply to nw1905 from comment #20) > When can we expect this to be in a tagged release? broadly guessing from git > history it seems there was about a month between `24.12.0`, `24.12.1` and > `24.12.2`, so can we expect this to land in a `24.12.3` in early march? > > Or is this just a coincidence and we might get it earlier? KDE Gears (of which dolphin is part of) maintenance release are monthly. As are almost all KDE maintenance release btw... So far, chances are low this will be fixed in the next release.
(In reply to Méven from comment #21) > (In reply to nw1905 from comment #20) > > When can we expect this to be in a tagged release? broadly guessing from git > > history it seems there was about a month between `24.12.0`, `24.12.1` and > > `24.12.2`, so can we expect this to land in a `24.12.3` in early march? > > > > Or is this just a coincidence and we might get it earlier? > > KDE Gears (of which dolphin is part of) maintenance release are monthly. > As are almost all KDE maintenance release btw... > > So far, chances are low this will be fixed in the next release. But it is already fixed in GIT.
(In reply to Guido from comment #22) > (In reply to Méven from comment #21) > > (In reply to nw1905 from comment #20) > > > When can we expect this to be in a tagged release? broadly guessing from git > > > history it seems there was about a month between `24.12.0`, `24.12.1` and > > > `24.12.2`, so can we expect this to land in a `24.12.3` in early march? > > > > > > Or is this just a coincidence and we might get it earlier? > > > > KDE Gears (of which dolphin is part of) maintenance release are monthly. > > As are almost all KDE maintenance release btw... > > > > So far, chances are low this will be fixed in the next release. > > But it is already fixed in GIT. Please don't make me justify all the things please and read the previous messages. It is a waste of time for me and not useful for you, unless you meant to actually do something about it yourself. With a little effort you can find all the answers yourself. All our development is opened. `master` branch is fixed thanks to https://invent.kde.org/system/dolphin/-/merge_requests/889 as already mentioned here. https://bugs.kde.org/show_bug.cgi?id=498211#c12 But that's a big change I am not very comfortable backporting. Only part of it needs to be backported.
Honestly, it doesn't seem like that big a change to me, it's a lot of lines simply because the same thing is changed in many places in the code, but it's nothing that challenging. If, however, you say that only part of this commit is actually needed to fix the bug, then I don't see the problem. After that, the project is yours to do with as you please. Thanks for the correction, but try to keep your cool.
(In reply to Guido from comment #24) > Honestly, it doesn't seem like that big a change to me Well if a KDE Devs judges it's a big change, then unless you are also are one, I would not feel entitled to speak over them and instead would trust their judgment as they will know better how the proposed change might impact things (and it's not necessarily about the number of lines). That said don't understand this: (In reply to Méven from comment #23) > But that's a big change I am not very comfortable backporting. > Only part of it needs to be backported. No-one is asking for "backporting" as far as I can tell. They wonder if it'll be included in the "next" release 24.12.3 (which seems sensible and legitimate as there is clearly a regression that happened in 24.12.2). Sorry if I'm missing something, but I have read the previous messages and I don't understand. Now your last message gives a clue which is: "the change is too big and needs more testing for it to be included in the next release", which if this is what you mean, was not clear before (at least to they layperson).
(In reply to Gauthier from comment #25) > (In reply to Guido from comment #24) > Well if a KDE Devs judges it's a big change, then unless you are also are > one, I am not, but neither am I stupid enough not to know how to read a few lines of code. > That said don't understand this: > > (In reply to Méven from comment #23) > > But that's a big change I am not very comfortable backporting. > > Only part of it needs to be backported. > > No-one is asking for "backporting" as far as I can tell. They wonder if > it'll be included in the "next" release 24.12.3 (which seems sensible and > legitimate as there is clearly a regression that happened in 24.12.2). This is exactly what I was saying. If a regression was introduced in a monthly point release, its correction makes sense in the next one.
(In reply to Guido from comment #26) > I am not, but neither am I stupid enough not to know how to read a few lines > of code. I doubt KDE devs would purposefully leave their software broken for longer than necessary. I agree with you their response was a little brutal and confusing, but you know, I don't think you are stupid, nor do I think they are so they are also saying this for a reason, therefore I believe the way to engage with them to find out is not to be dismissive of their approach. Btw, calling stupid anyone who cannot read a few lines of code is also a bit brutal. And I was not implying you can't read code, but that as a non KDE dev they might be other implications (maybe even outside dolphin) you not have considered, that was all.
(In reply to Gauthier from comment #27) > are so they are also saying this for a reason, therefore I believe the way > to engage with them to find out is not to be dismissive of their approach. The bug arose from a previous commit, which was evidently not adequately tested. The new commit mainly corrects the previous commit. There is nothing strange about this. > Btw, calling stupid anyone who cannot read a few lines of code is also a bit > brutal. Sorry, I did not mean to make that implication in any way, I simply meant that a correction that is repeated 100 times is still one correction. > And I was not implying you can't read code, but that as a non KDE > dev they might be other implications (maybe even outside dolphin) you not > have considered, that was all. In general it is possible, but this is not the case, either by looking at the code involved or by using Dolphin from GIT where there are no obvious problems.
In any case, I don't want to keep insisting, they can do as they see fit, the project is theirs, I am no one to tell them what to do.
Created attachment 178618 [details] Nextcloud folder - Dolphin from Git I install dolphin from Git, and while there is a clear improvement which makes it usable again, it's still looking odd. The green tick icon on Nextcloud folder are way outside to the left of the folder icon itself which wasn't the case before and which make all folders look unnecessary wide. See screenshot.
(In reply to Gauthier from comment #30) > Created attachment 178618 [details] > Nextcloud folder - Dolphin from Git > > I install dolphin from Git, and while there is a clear improvement which > makes it usable again, it's still looking odd. The green tick icon on > Nextcloud folder are way outside to the left of the folder icon itself which > wasn't the case before and which make all folders look unnecessary wide. See > screenshot. That's new expected behavior, it depends on the zoom level. That's not the same thing as the bug here. Please don't pollute bug report with unrelated things. Thanks.
Created attachment 178628 [details] Nextloud icons Dolphin 24.12.1 (In reply to Méven from comment #31) > That's not the same thing as the bug here. > Please don't pollute bug report with unrelated things. Thanks. Sorry for my ignorance, it seemed related since the changes are a direct consequence of what's been discussed here (and this bug report was pointed to from the Nextcloud forum on this issue). Happy to report it elsewhere if here isn't the place. I'm using my spare time to report bugs and do my bits to improve KDE, but as all human, I make mistake. > That's new expected behavior, it depends on the zoom level. Ok, I saw that changing the zoom brings the folder and tick together but it only looks normal at huge zoom levels. Frankly it still looks like a regression compared to 24.12.1 (see screenshot of how it was before).
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/912
(In reply to Bug Janitor Service from comment #33) > A possibly relevant merge request was started @ > https://invent.kde.org/system/dolphin/-/merge_requests/912 Thank you Maven! A side question: why tooltips have been removed in Dolphin (git)
(In reply to Guido from comment #34) > (In reply to Bug Janitor Service from comment #33) > > A possibly relevant merge request was started @ > > https://invent.kde.org/system/dolphin/-/merge_requests/912 > > Thank you Maven! Méven ;-) > > A side question: why tooltips have been removed in Dolphin (git) Don't ask random question in bugs please, that's noise. Wasting time for bug followers and developers alike. Use discuss.kde.org for that. There aren't removed, you might be missing baloo-widgets dependency.
https://invent.kde.org/system/dolphin/-/merge_requests/912 was merged it should fix the worst issue (icons too small). The fix for overlay icons will be for 25.04.
It looks like it has not been mentioned, but in Dolphin (24.12.2) soft link to file/folder that have a generated thumbnail (like a picture thumbnail or folder with preview of his content) have their overlay emblem, above a zoom threshold, suddenly becoming smaller than those of other files/folders. I have mentioned this in bug 500624 (about the thumbnail in general at the threshold).
*** Bug 500995 has been marked as a duplicate of this bug. ***
I'm pleased to report that 24.12.3 solved the small icon/thumbnail issue, say with Nextcloud folders. Additional bonus is that the green tick (bottom right of the folder icon) and the share icon (top left of the folder icon) are now looking good, much better than in the git version from a couple of weeks ago where it was looking rather odd (though according to Méven the odd looking one was supposedly the intended behaviour).
Weirdly, since the fix some of my folders went from too small to too big where the icon overflows and gets cut off: https://ibb.co/5gqzGd8W
So it seems fixed. Hasn't it been fixed for every case ?
(In reply to Dimitri from comment #41) > So it seems fixed. Hasn't it been fixed for every case ? I confirm it is fixed.
Created attachment 185213 [details] File sync overlay icons with 100% display scaling Unfortunately I still see issues with dolphin 25.08.1. The overlay icons become smaller with off-normal icon aspect ratios, and when using screen scaling, the borders are cut off and some icons are not well-aligned / scaled.
Created attachment 185241 [details] overlay with 125% scaling Something weird is going on with display scaling, for me it looks like the emblem gets cut off. Also the icon sizes seem to change on hover. Operating System: Fedora Linux 42 KDE Plasma Version: 6.5.80 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.16.8-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
Some analysis: KStandardItemListWidget::updatePixmapCache does not work well with KStandardItemListWidget::addOverlays The m_scaledPixmapSize m_pixmapPos enter in conflict with the way addOverlays modifies the end result pixmap.
I can confirm this issue is back with dolphin 25.08.1.
Created attachment 185578 [details] Dolphin 25.08.1 thumbs + overlay I have attached how thumbs appear in Dolphin 25.08.1 when there is an overlay icon. They appear much smaller than they are for files without overlays.