Bug 435226 - File preview limited in size
Summary: File preview limited in size
Status: CONFIRMED
Alias: None
Product: dolphin
Classification: Applications
Component: panels: information (show other bugs)
Version: 19.12.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: usability
Depends on:
Blocks: 434316
  Show dependency treegraph
 
Reported: 2021-04-01 17:14 UTC by fleury
Modified: 2021-04-08 18:34 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshot of when the file does not fill the full information panel (1.42 MB, image/png)
2021-04-01 17:14 UTC, fleury
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fleury 2021-04-01 17:14:03 UTC
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
Comment 1 Nate Graham 2021-04-01 22:37:02 UTC
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.
Comment 2 fleury 2021-04-01 23:00:36 UTC
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).
Comment 3 oren.a4 2021-04-08 13:23:10 UTC
Isn't this bug duplication of this one - https://bugs.kde.org/show_bug.cgi?id=434316
Comment 4 Nate Graham 2021-04-08 18:34:15 UTC
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.