OK, it was RFC, I wanted to know whether I'm doing the right thing or not at all. Sorry for not specifying this in the first place.

About magic number and "text is way too big for the size of the icons". I calculated this number simply by using 2 numbers: initial icon size and initial font size. 10/16=0.625. In my opinion, it looks OK.

Anyway, should I continue working in the same direction, or not?

I think this could potentially work with a lot more design and visual polish. Right now we're not even to the point where we can discuss whether or not it looks good; we're still in "it's too buggy to actually use" territory, so we have to fix those bugs first. I outlined three such bugs in my initial comment.

I'm not convinced at all the text size should change. This would make it impossible to have normal-sized text and choose the item size independently, in particular (but not only!) for previews.

What's the use case for having larger text? As far as I understand, the zooming feature is for previews and for having larger click targets in the viewport. Text size should be set in System Settings or Dolphin's config.

Neither Windows Explorer, nor macOS Finder combine zooming icons and text. To me it seems the reporter does not know about KMag or KWin's magnifying glass, or wants easier access to changing the font size. However, that niche use case should not break the feature for nearly everyone else.

When I made a positive comment in the bug report, what I had in mind was that the text would very selectively and conditionally become a bit larger when the icon size is huge. Because right now, 10pt font with 256pt icons just looks silly:

Whereas increasing it to 15pt looks a lot more appropriate IMHO:

But I think it would have to be hand-tuned, rather than just implementing a simple linear scaling factor like this patch does.

If everybody thinks I'm smoking crack and nobody else wants to do it, we should WONTFIX the bug.

In D11135#221297, @ngraham wrote:

When I made a positive comment in the bug report, what I had in mind was that the text would very selectively and conditionally become a bit larger when the icon size is huge. Because right now, 10pt font with 256pt icons just looks silly.
Whereas increasing it to 15pt looks a lot more appropriate IMHO.
But I think it would have to be hand-tuned, rather than just implementing a simple linear scaling factor like this patch does.

+1. But we should not forget about user configured font size. I.e. if the user configured to use font size 14, then we should scale it to 21 (but not 15) for 256pt icons.

In D11135#221386, @rominf wrote:

In D11135#221297, @ngraham wrote:

When I made a positive comment in the bug report, what I had in mind was that the text would very selectively and conditionally become a bit larger when the icon size is huge. Because right now, 10pt font with 256pt icons just looks silly.
Whereas increasing it to 15pt looks a lot more appropriate IMHO.
But I think it would have to be hand-tuned, rather than just implementing a simple linear scaling factor like this patch does.

+1. But we should not forget about user configured font size. I.e. if the user configured to use font size 14, then we should scale it to 21 (but not 15) for 256pt icons.

Right, exactly! If you re-did this patch along those lines, I think we could take a serious look at it.

@ngraham What you are essentially saying is that you find the font size in Gwenview's Browse mode (which shows exactly those "large" type of items like in Dolphin, i.e. thumbnails) too small, and even if the user set it to a normal size you would just increase it a bit, making it look inconsistent and frustrating the user.

We can already set the icon size as well as the text size. What you are doing here (under the name of "increase the text size") is to combine both into a dynamic slider. Would you also suggest to increase the size of all UI elements when someone maximizes a window? Or attach a slider to the menubar so users can quickly increase that size?

This is not a zoom slider like on a web page, where you temporarily increase the size. The slider is used to permanently select a size of the icons/previews, and if there is no way to combine that setting with having a normal/permanent text size, that's bad. Where do you make the cut for turning off the feature? For 128px? For 64px? What about HiDPI, or custom default font sizes? I don't think your plan will work, and it's better to have it looking a bit odd like in your screenshot, than to create problems in all other cases.

I.e. if the user configured to use font size 14, then we should scale it to 21 (but not 15) for 256pt icons.

If I configure a size for text and another size for icons, I want to get exactly that, and not something different. (Also note that if Use common properties for all folders is selected, the slider and the config entry for the default icon size are linked together.)

Anyway that's just my take on it, better ask more of Dolphin's maintainers about it before putting too much work into a patch.

My two cents: You can configure both icon size and text size, for each view mode separately. This configuration can be considered the permanent state.

Now the question is, why would one temporarily increase the icon or the text size? The only reason I can come up with is when you are looking at a folder of image, video, or text thumbnails, and those reveal more information with larger icon sizes. To me that is exactly the use case for the zoom slider.

In D11135#221549, @cfeck wrote:

My two cents: You can configure both icon size and text size, for each view mode separately. This configuration can be considered the permanent state.

Now the question is, why would one temporarily increase the icon or the text size? The only reason I can come up with is when you are looking at a folder of image, video, or text thumbnails, and those reveal more information with larger icon sizes. To me that is exactly the use case for the zoom slider.

@cfeck So to be clear: Increasing the text size does not reveal more information, and thus it should not be increased in sync?

Right, sorry if this wasn't clear.

In D11135#221495, @rkflx wrote:

If I configure a size for text and another size for icons, I want to get exactly that, and not something different. (Also note that if Use common properties for all folders is selected, the slider and the config entry for the default icon size are linked together.)

Then you'd better go complain to Plasma and QQC2-desktop-style and Kirigami, because they all use a Heading control that essentially does exactly what this patch adds to Dolphin: provides a text label whose font size is some multiplier of the size you actually chose. It is commonly used for non-headings, as its smallest size "5" is equal to the size you set. 4 is a little bigger, 3 is a bit bigger, and so on, until you get to 1, which is an actual header-sized text label.

The point here is to allow standardized font sizes to be played with according to the designer's intent. Sometimes a slightly larger text size looks better in some situations. That's really all it is.

In D11135#224260, @ngraham wrote:

In D11135#221495, @rkflx wrote:

If I configure a size for text and another size for icons, I want to get exactly that, and not something different. (Also note that if Use common properties for all folders is selected, the slider and the config entry for the default icon size are linked together.)

Then you'd better go complain to Plasma and QQC2-desktop-style and Kirigami, because they all use a Heading control that essentially does exactly what this patch adds to Dolphin: provides a text label whose font size is some multiplier of the size you actually chose. It is commonly used for non-headings, as its smallest size "5" is equal to the size you set. 4 is a little bigger, 3 is a bit bigger, and so on, until you get to 1, which is an actual header-sized text label.

The point here is to allow standardized font sizes to be played with according to the designer's intent. Sometimes a slightly larger text size looks better in some situations. That's really all it is.

The different sizes you talk about conceptually correspond to the different static sizes users can set in the fonts KCM (e.g. title, normal text, small text etc.), only that they follow a more modern approach with sizing, rooted in desktop publishing and web design. There's nothing wrong with that.

What tickled me was the proposal to dynamically bind the font size to a zoom slider controlling the icon size. That's not something I've seen elsewhere so far, not even in Kirigami apps.