Replies: 7 comments 1 reply
-
I'm certain that there are users expecting a different behavior. But this is the case for all automatisms.
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 scaling works the best if you don't maximize the window and adjust the window size to show the cover sizes you want to see. And this is usually the case on larger monitors.
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.
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.
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 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. |
Beta Was this translation helpful? Give feedback.
-
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 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! |
Beta Was this translation helpful? Give feedback.
-
|
Adding 100 to all # 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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I've change the automatic scaling such that the covers always use all available space. The breakpoints should now be way easier to adjust as they just describe when to use more columns. I've also converted this thread to a discussion as this should be more appropriate to discuss things than a closed issue. |
Beta Was this translation helpful? Give feedback.
-
|
The cover in the detailed album view now scales independently and uses exactly half the available space. This could be adjusted to any fraction. |
Beta Was this translation helpful? Give feedback.
-
|
Digging this! Thank you for putting up with me. Also behaves much more intuitively, from a UX experience. |
Beta Was this translation helpful? Give feedback.
-
Description
41c5f0c introduced automatic album art scaling. While I completely agree that album covers should scale automatically (rather than this being exposed as an user-facing setting), I'm not sure if the current scaling behavior works as users would expect.
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.
(IIRC, scaling on my external 4k monitor worked a bit better. Will check when I get home)
Observed behavior
t.mp4
Expected behavior
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.
The screenshots in this repo's README file resemble the scaling I would expect.
Beta Was this translation helpful? Give feedback.
All reactions