imagebox: add a "cover" fit policy

[Delta-official]

This fit policy emulates the behaviour of CSS' background-size: cover

[Elv13]

Hello,

Can you edit the following 2 files and post a screenshot of the result? This should regenerate the 2 images you see in the doc.

https://github.com/awesomeWM/awesome/blob/master/tests/examples/wibox/widget/imagebox/horizontal_fit_policy.lua
https://github.com/awesomeWM/awesome/blob/master/tests/examples/wibox/widget/imagebox/vertical_fit_policy.lua

[Delta-official]

cover only really works if you set it on both vertical and horizontal policies

[Elv13]

cover only really works if you set it on both vertical and horizontal policies

In that case, there's probably some interaction with valign and halign. It might be worth to add new example images to the documentation to reflect that. The easiest way to do that is to copy paste an existing example file and modify it. You need to add the @DOC_path_to_file_EXAMPLE@ line in the property documentation.

[codecov]

Codecov Report

Merging #3811 (e3990e4) into master (b13ac3e) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #3811   +/-   ##
=======================================
  Coverage   90.99%   91.00%           
=======================================
  Files         900      900           
  Lines       57506    57512    +6     
=======================================
+ Hits        52329    52336    +7     
+ Misses       5177     5176    -1     

Flag	Coverage Δ
gcov	91.00% <100.00%> (+<0.01%)	⬆️
luacov	93.71% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
lib/wibox/widget/imagebox.lua	96.46% <100.00%> (+0.03%)	⬆️
...es/wibox/widget/imagebox/horizontal_fit_policy.lua	100.00% <100.00%> (ø)
...ples/wibox/widget/imagebox/vertical_fit_policy.lua	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

[Delta-official]

cover only really works if you set it on both vertical and horizontal policies

In that case, there's probably some interaction with valign and halign. It might be worth to add new example images to the documentation to reflect that. The easiest way to do that is to copy paste an existing example file and modify it. You need to add the @DOC_path_to_file_EXAMPLE@ line in the property documentation.

it does appear to. valign only works if the image has excess vertically and halign works only if there's excess horizontally (basically the same behaviour as if you did fit and none)

[Delta-official]

is this good?

[sclu1034]

On a general level, I'll want to throw in that imagebox has already become rather complex, and that I'm not sure if we really should keep piling more things on top of that.

For the change itself, the result in the latest screenshot doesn't match what I would expect from the description and name of the option.
When I read "cover", I'd expect the image to be scaled just so that it fills out the given space. But looking at the variant where both properties are set to "cover", the image is clearly cropped both horizontally and vertically. Given that the original has more height than width, I'd expect the image to be scaled such that the width fits perfectly, and only the top and bottom to be copped.

[actionless]

i'll just throw in how it's described in css spec, so everyone would have the same understanding of how it expected to work:

cover

The replaced content is sized to maintain its aspect ratio while filling the element's entire content box. If the object's aspect ratio does not match the aspect ratio of its box, then the object will be clipped to fit.

https://w3c.github.io/csswg-drafts/css-images/#the-object-fit

[sclu1034]

If we do go with the CSS spec, then the smallest rectangle is where the above screenshot doesn't comply with the constraint:

A cover constraint is resolved by setting the concrete object size to the smallest rectangle that has the object’s natural aspect ratio and additionally has neither width nor height smaller than the constraint rectangle’s width and height, respectively.

[actionless]

i specifically posted the pics in case if anyone would have troubles with english

[sclu1034]

I meant the image from delta that demonstrates the proposed change, not the one from MDN.

[actionless]

yup - that's the intention, to make it visible side-by-side

i think the problem that both W and H are computed as max, whilst it should be done only for one of the aspects, and other computed from it

[actionless]

😹

[alanswanson]

This is the same as #3554 and will probably have the same issue as #3547 (comment). Shame that awesomwm is essentially a dead project.

[actionless]

@alanswanson your PR is missing doc examples and tests as in this one - mb you could combine effort to make one good PR from two 😺

[sclu1034]

@actionless As mentioned in #3547 (comment), they were waiting for the code changes to be reviewed before spending time on docs.
But that's still drifting on a "ping Elv", and will continue to do so, given that Elv doesn't seem to have much time for the project these days. You and @Aire-One might have to step up and get some reviews in without him for the project to keep moving.

[actionless]

e to step up and get some reviews in without him for the project to keep moving.

that's what i did in the comment above - that information should be enough to make one of PRs merge-able