I've just checked it with a fresh config and initially I also could not see this issue (a single-row horizontal panel with fixed icon size set to 16). I was still able to reproduce this issue but only for very wide panels. Setting the fixed icon size to 32 and number of rows to 3 made it more obvious.
It looks like this is related to the automatic calculation of the number of rows in the window buttons plugin. Two issues with it:
Scaling looks too aggressive for horizontal/vertical panels, resulting in rows inside the plugin getting progressively narrower/smaller as the panel size increases. Icon size follows the button height (interestingly only for larger panels)
In the deskbar mode, button height should be fixed, independent from the panel/deskbar width (this is where I noticed this issue first but it didn't look limited to the deskbar mode).
A suggestion: perhaps the window plugin could have its own option for the number of rows settings rather than try to calculate it from the panel size?
I don't think this behavior is aberrant: a certain proportion is maintained between the size of window buttons and their icons, so that if window buttons decrease in size (as the number of tasklist lines increases), the size of icons follows. The size specified for icons in the panel preferences is therefore to be regarded as a maximum in this case, but then again, that's understandable.
I am not familiar with #196 (closed) and the concept for row ratios introduced in this commit, so if I was to fix this issue I would likely break something else. Would you be able to look into what went wrong?
When bisecting I was only testing the behaviour in the deskbar mode, so I am quietly assuming the decreasing button/icon sizes in other modes is caused by the same issue, perhaps not.
Commenting out lines 2703 and 4184 in 83fa5ead fixes the issue but it essentially disables the nrows_ratio mechanism added in this commit.
At very least I would like to set nrows_ratio=1 in the deskbar mode (concept of nrows does not apply here) but frankly speaking I think we would be better off not using nrows_ratio at all.
The only other use case where shrinking icons would be desirable (that I can think of) is clamping the icon size to fit in smaller buttons like in this example:
But:
This can be achieved with option "Icons: Adjust size automatically"
If a fixed icon size is required, then a better solution would be to simply clamp the icon size to fit in the button:
Created !149 (merged) that clamps the icon size to the button size instead of resizing icon size based on nrows_ratio. This assumes there are no other scenarios for the nrows_ratio but I have tested the code in all configurations I could think of I did not see any regressions.