Bug 452139

> 1. Use a 4K monitor and no scaling.
Welp, found your problem. :) Not using the systemwide scaling feature and trying to manually make every individual thing bigger isn't supported, and causes issues like this. I recommend using the scaling system instead.

> Currently it looks like the maximum and minimum sizes are hard-coded as pixel values. A better
> approach may be to use a percentage of the width of the window that the icons are displayed in
> to scale the icons, from, let's say 10% to 100%, would fit ten Icons to fitting only 1 Icon.
That would be quite unpredictable as the icon sizes would scale up and down as you change the window size We'd give people seizures lol. :)

Hi there, and thanks for the quick reply. 
The whole reason I got a high resolution monitor is to actually use that resolution. Photo editing and video editing works better at native resolution. The scaling feature negates the whole high resolution bit, and causes a whole host of other issues, so scaling is a non-starter.
In my defense, I did try to use it, but found the trade-offs unacceptable.

Just a higher maximum size would already go a long way to cure this issue.

I would expect a pro app like kdenlive to handle this automatically, and de-scale the raw video footage when the UI is scaled (which is the point of scaling).

Unless you have a truly enormous screen, not using any scaling with a 4k resolution would result in every UI element being incredibly tiny, requiring pinpoint mouse precision to manipulate. Is this truly what you're dealing with? Or is your screen large enough that things don't really need scaling? How big is the screen?

Created attachment 147901 [details]
Screenshot of application in X11 at 150% Zoom

This shows the application in X11 with a 150% Zoom.
The icons on the left browser  is in kdenlive' s own Project bin, where you collect clips to play with. 
The icons on the right are in the kfilewidget, and at maximum zoom.

Created attachment 147902 [details]
Screenshot of application in X11 at 100% Zoom

This is my default view, with zoom level of 100%, and a forced font DPI of 144. 
Again, note the size difference between the internal icon browser and the kfilewidget on the right.

Created attachment 147903 [details]
Screenshot of application in Wayland at 125% Zoom

For completeness, here is the application in Wayland at 125% zoom.

> This is my default view, with zoom level of 100%, and a forced font DPI of 144. 
Ah, so you are using scaling after all, but sort of handmade cobbled-together scaling, and not the official one. I'm afraid this an explicitly unsupported setup; you're on your own if you use it. If you want 150% scale, my recommendation is just use 150% scale with the official method, which looks much better to me in your screenshot. If somehow kdenlive doesn't support that properly, it's an issue in the app itself and I would encourage you to report it to them.

Hi there!

Thanks so much for coming back to me on this. The monitor is pretty big, but not super-massive, at 32"
I have attached a couple of screenshots to show Kdenlive in action, with various settings that are comfortable for me to work in. 

As you can see, the scaling has some effect, but not as much as I would have hoped for. In all the cases, the kfilewidget's icons at maximum size is still a little small for me, and the space wasted between the icons seeming excessive. 
Thanks for the tip on F9 for the panel, it works a treat!

Kind regards,
-Evert-

In the first screenshot I was using the official scaling method. And I quite like it, too. 
It's a shame about that display bug, and I definitely will be reporting it up to the Kdenlive developers. 

Unfortunately, even with the official scaling the icons in kfilewidget are not big enough, and the space between the icons seems excessive.

I'm glad that 125% or 150% scale look better.

Regardless of scaling, you may be right here, though. Dolphin lets you go up to 256px, and Gwenview allows 512. Screens are getting bigger, regardless of scaling. Maybe it would be reasonable to allow the maximum to be 256.

One issue I foresee with this is that it would make finely adjusting the size harder, since the slider used to change the scale wouldn't get any bigger and it is already quite small. So each "step" on the slider would be twice as large.

Hi there, Nate. 

Just played a bit with the widget, and of course on smaller screens you are right, the step size when dragging the icons will become larger. and it may be annoying to get the size exactly right. 

Which is why I was thinking of going the HTML scaling way, and dynamically scaling the icons based on the display width, and the setting then being how many columns of icons you want in the window... But that could turn out an ugly ugly for the reasons you so rightly laid out.

When scrolling the mouse wheel on it, the size does change nice and slow. Nothing is ever simple, is it? 

This may be a stupid idea, but what about putting the size adjuster in a popup?

Supposedly when you activate the slider by clicking on it, it pops up to a much bigger slider that allows for fine adjustment, and then once your pointer goes off it, it pops back down.... I don't imagine people are adjusting their icon size all the time, so it won't be distracting. It may even look fancy, but involve much more coding than just increasing the maximum number. It's all up to you, I suppose. 

Thanks again for at reading through my report. :)

Git commit 4b0b91d39d8a4f7f0f044f3589b5c7de671044c1 by Ahmad Samir.
Committed on 06/05/2022 at 17:51.
Pushed by ahmadsamir into branch 'master'.

KFileWidget: allow icon sizes to go up to 512

Nowadays monitors are getting bigger, and resolutions are getting higher,
so bigger icon sizes make sense for the bigger image previews use-case.

Change the icons slider to only allow standard icon sizes:
- with the range being 16-512, the slider handling code would be much more
  complicated to be usable (would have to use a logarithmic scale)
- icons look best when at a standard size (otherwise scaling is involved
  and they don't look as good)
- this is the "open file dialog", typically one would use this dialog for
  less than 1 minute, to open/save a file, so the fine-grained icon size
  control isn't needed, and 16, 22, 32, 48...etc pretty much cover a wide
  range already.

This is going back to not having 1:1 (1px icon size == 1 step on the slider)
scale on the slider, but instead of having the logic to handle that in
KDirOperator, I left KDirOperator as-is using setIconSize(actual-icon-
size), and instead implemented the logic in KFileWidget by tweaking the
slider handling code, I think it's simpler that way.

Also use the new enum values from KIconLoader::StdSizes.
FIXED-IN: 5.94

M  +3    -2    src/filewidgets/kdiroperator.cpp
M  +51   -59   src/filewidgets/kfilewidget.cpp

https://invent.kde.org/frameworks/kio/commit/4b0b91d39d8a4f7f0f044f3589b5c7de671044c1

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/62