| Summary: | File preview limited in size | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | fleury |
| Component: | panels: information | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | kfm-devel, nate, oren.a4 |
| Priority: | NOR | Keywords: | usability |
| Version: | 19.12.3 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 434316 | ||
| Attachments: | screenshot of when the file does not fill the full information panel | ||
It looks like the preview that's shown here is simply the thumbnail that's already been generated, to save resources. This thumbnail is a maximum of 256x256, which is according to the FreeDesktop.org thumbnail spec. So one of two things would have to happen here: 1. The FDO spec permits the generation of larger thumbnails, and then this preview could consume those larger previews 2. The preview widget generates the previous dynamically, rather than re-using the existing thumbnails The downsides to option 1 are bureaucracy and the possibility that it wouldn't work at all; even a 512x512 thumbnail isn't that big at 200% scale, and a 1024x1024 thumbnail can't really be considered a thumbnail anymore, so it would probably not be accepted. The downsides to option 2 are increased resource consumption and reduced speed by re-doing already-done work by reading the file data ourselves rather than relying on an already-generated thumbnail image. I see. Well, it does it for images though. Images seem to be able to be significantly bigger than the max thumbnail size, and they get loaded. So there is a list of formats that could be loaded fully instead of using the thumbnail. Also funnily, GIMP images are shown as thumbnails in the list of files, but are not shown in the information panel... It would be really useful to be able to go through files fast (like for images). There is already an animation while things get loaded (the preview becomes black/white). Isn't this bug duplication of this one - https://bugs.kde.org/show_bug.cgi?id=434316 No, that requests being able to zoom into the preview image, which is a step beyond what's being asked for here. This is probably a blocker though, since it doesn't make much sense to offer a zoom feature if the thing to be zoomes can't even fit in its viewport as it is. |
Created attachment 137240 [details] screenshot of when the file does not fill the full information panel SUMMARY Preview of files is limited in size. STEPS TO REPRODUCE 1. Browse in a folder with e.g. a PDF file, mark the file 2. ensure the information panel is on, and the file preview is on 3. resize the divider so that the preview part changes in size. OBSERVED RESULT The PDF preview is resized to fit the infomation panel size, up to a maximum size and then stays at that size even if there is space around it. EXPECTED RESULT The PDF file is sized to use the maximum space provided by the information panel (while respecting margins and proportions). On 4k screens, this will let one navigate a cvollection of PDFs and be able to actually read their content in the preview. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 20.04 / kernel 5.4.0-70-generic KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION