https://bugs.kde.org/show_bug.cgi?id=420657
--- Comment #14 from myndstr...@protonmail.ch --- (In reply to Nate Graham from comment #12) > Nothing; that's just the way Debian works. If you want newer versions of KDE > software, you'll need to wait for the next major Debian version, switch to > Debian Testing, or switch to a different distro that ships more recent > versions of KDE software. I asked about it here: https://unix.stackexchange.com/questions/584892/what-would-be-needed-by-debian-to-ship-newer-versions-of-the-kde-desktop-environ > Why not? That's how things get fixed. There were just too many (many of which probably due to the same underlying issue) and apparently, as you wrote, they have already gotten fixed in newer versions. I think many of the bugs depend on what I configured in other display-settings and it would be easy to test and better to make sense of by people with knowledge of the code. Also I'd like to not use the scaling due to the bugs. For reporting bugs related to it I would need to use a newer version so I don't report bugs which have already been solved but I'd like to stay with Debian stable (hence the question linked above might also be relevant to this). > In principle I'm not against adding a 512 size. Unfortunately a technical > blocker is the fact that the XDG thumbnail spec only goes up to 256px. So we > would not actually have any 512px thumbnails to display for the new larger > 512px icons. This is a thing that irritates me in other contexts too, but we > need the XDG thumbnail spec to be updated first before we can consider 512px > thumbnails. Okay, that's interesting. In that case the issue for that in XDG thumbnail spec should probably be linked in issues related to it. Do you have a link to the issue (I guess somebody created it already)? (In reply to Christoph Feck from comment #13) > I am against saving 512 px icons. Since these are losslessly stored, they > could end up larger than the original JPEG, defeating the purpose of the > cache. Good point. But maybe, and as originally proposed, it could be made a per-directory view-option. Later there could also be some code that allows storing only a low-resolution thumbnail and quickly increasing the thumbnail resolution when the thumbnail is in or near the current field of view. After the view is closed the newly created cache created by the higher resolution thumbnails would get cleared again. > What I hoped for was that Dolphin simply scales the thumbnails (it does so, > anyway, but only to scale them down), like we added for Gwenview. Imo that would be a good near-term / somewhat improvised solution. It would be an implementation of: - increasing the maximum zoom level and/or - giving users the option to configure the maximum zoom level (or multiple options like a maximum zoom level for each view mode) with the maximum zoom level being larger than what the resolution offers. Because scaling/zooming above resolution-boundaries doesn't look well I'd opt for a view-option rather allowing it by-default. -- You are receiving this mail because: You are watching all bug changes.