Feedback on new album cover scaling algorithm about plattenalbum HOT 5 CLOSED

I'm not sure if the current scaling behavior works as users would expect.

I'm certain that there are users expecting a different behavior. But this is the case for all automatisms.

Most importantly, album art on my laptop screen (2256x1504 resolution) is often way smaller than I would expect, especially when compared to the screenshots you provide in the project's README.md.

It is to be expected that there are window/screen resolutions with suboptimal cover sizes. If you have a suggestion for a more consistent scaling please let me know about it.

IIRC, scaling on my external 4k monitor worked a bit better. Will check when I get home

I think scaling works the best if you don't maximize the window and adjust the window size to show the cover sizes you what to see. And this is usually the case on larger monitors.

Two album covers are oftentimes displayed in a "three-column view" when mpdevil runs as maximized window. However, given the available real estate, I would expect them to be displayed in a "two-column view":

I'm not sure how you mean that. Would you display the albums of different artists with different cover sizes if there are only one or two? If so, I don't like it at all. This introduces completely superfluous complexity.

Sometimes, having more real estate available will lead to smaller album covers, as I have attempted to demonstrate in the video below. I would expect the opposite: the size of the album art should only grow as the size of the window grows.

Yes, I'm aware of that. This is intended. Otherwise it wouldn't be possible to choose between larger covers with fewer columns and smaller covers with more columns. Unless one allows the number of columns to decrease when the window size increases. But one of those to numbers (cover size and number of columns) has to be able to decrease when the window size increases. But again, maybe you have a better scaling scheme in mind.

Album covers are nice too look at (and primary UI elements!), and hence, should cover as much area as makes sense. That is, they should scale with the available real estate.

Which is what I tried to achieve. With my scaling approach the jumps between the amount of covered space are relatively small due to a potential decrease in cover size when the number of columns goes up. And small jumps in the amount of covered space directly translate to a better usage of available space.

The screenshots in this repo's README file resemble the scaling I would expect.

The screenshot currently in the README resembles the default settings of current master. So it uses the current scaling method. The pictured window size is exactly what you would get on first install.

from plattenalbum.

It is to be expected that there are window/screen resolutions with suboptimal cover sizes. If you have a suggestion for a more consistent scaling please let me know about it.

I think I might have underestimated the complexity of the issue, actually. As you point out, dealing with cases where one only has one or two albums by an artist in one's library will most likely introduce undesirable complexity to the code.

So, I think everything might fine after all — it's just that I had gotten used to the covers being much larger than they are now, thanks to the recently removed "album art size" setting. In that regard, tweaking the new breakpoints you introduced might bring things closer to my liking: perhaps reducing the rate in which AlbumListRow splits into columns might make things look better at my preferred window sizes.

If I happen to find breakpoint settings I think would look better (a difficult judgement indeed, due to subjective nature of all of this), or in fact a completely different solution/algorithm, I might re-open. Thank you for your time!

from plattenalbum.

Adding 100 to all cover_sizes here indeed helps:

# for width, cover_size in ((396,180), (504,150), (594,180), (702,216), (792,180), (936,216), (1108,259), (1170,216), (1385,259)):
for width, cover_size in ((396,280), (504,250), (594,280), (702,316), (792,280), (936,316), (1108,359), (1170,316), (1385,359)):
			break_point=Adw.Breakpoint()
			break_point.set_condition(Adw.BreakpointCondition.parse(f"min-width: {width}px"))
			break_point.add_setter(settings, "cover-size", cover_size)

before

after

I think the values I have used in second screenshot generally get a lot closer to the screenshot you have provided in the README. Moreover, it makes album covers more like big UI elements, which I believe we're both fond off (though adding 100 might be overdoing it)

But then again, there's no arguing over taste. Perhaps it's just that my own library benefits from this, since I tend to only have 1 or 2 albums per artist.

Fairly uninformed guess, but maybe screen resolution/DPI scaling is also a factor here? Now, the values are hardcoded, which might lead to a lot of negative space in some cases.

from plattenalbum.

Simply adding 100 to the cover sizes breaks the whole algorithm. The numbers were precisely chosen such that when a breakpoint applies the cover perfectly fit, this is now not the case any more.

Fairly uninformed guess, but maybe screen resolution/DPI scaling is also a factor here? Now, the values are hardcoded, which might lead to a lot of negative space in some cases.

I just thought of that as well. The normal toolkit scaling is respected since the pixel values are scale aware. This means one pixel in the code actually amounts to two real pixels if you scale the GUI by a factor of two. In fact I'm using a 4k monitor myself combined with the experimental fractional scaling of GNOME (150% in my case). And this is perfectly compatible with the hardcoded pixel values.
But a DPI change has no influence on the cover sizes in the album list while it has an impact on the main cover on the right. Are you using a non default DPI value?

from plattenalbum.

Ok, from my testing it seems like with your screen resolution combined with 200% GUI scaling is kind of an edge case. Just a few pixels more in width would cause an increase in cover size. But still three columns would be used.

from plattenalbum.