Wallpapers should be able to fill & keep proper aspect ratio (easy)

[olaf]

The wallpapers configuration window should allow users to use a smaller or larger wallpaper and stretch it properly. Properly, as in, keep the aspect ratio in tact while filling the screen (cropping some of either the width or height to compensate).

Additionally, but not necessary, allow it to be repositioned as well after being fit to the screen.

[stippi]

This patch is almost perfect. I think you need to compare aspect ratio of screen and bitmap in order to decide where to overlap. A bitmap may have to overlap at top/bottom OR left/right, depending on whether the aspect ratio is smaller or greater than the view aspect ratio, even though in both cases, the width may be greater than the height.

Other than that, the patch just needs to honor the 80 chars/line limit. :-)

[engleek]

Replacement for previous fix, with ratio comparing and obeying 80 chars style rule.

[engleek]

I'm not entirely happy with what I did with the 80 chars style rule. I did my best to make it still kind of understandable, but it's a bit tricky. Any guidelines for this rule?

[anevilyak]

Replying to engleek:

I'm not entirely happy with what I did with the 80 chars style rule. I did my best to make it still kind of understandable, but it's a bit tricky. Any guidelines for this rule?

In this instance it might make sense to break those calculations into their own functions, and call those from the switch cases, since they wouldn't be nested quite as heavily. Otherwise it might be prudent to just do the calculations in multiple steps instead of one giant statement as now.

[engleek]

Third version, with three extra private methods to apply the 80 chars style rule in a nicer way and improve modularity. Hopefully this won't have too much of a negative impact on performance.

[stippi]

I've tested the patch, Christopher, but there may be some problems. I have a wallpaper here which exactly fits the screen. But when I switch to the "Scale to fit" mode, the image gets suddenly stretched horizontally somewhat. Have not looked into why this might be.

[devheart]

In BRectHorizontalOverlap() and BRectVerticalOverlap(), it looks like engleek swapped the last hostRect.Width/Height in each equation.

In BRectHorizontalOverlap(), it should be

    return (((hostRect.Height() / resizedRect.Height()) 
            * resizedRect.Width()) - hostRect.Width()) / 2;

and BRectVertialOverlap() should be

    return (((hostRect.Width() / resizedRect.Width()) 
            * resizedRect.Height()) - hostRect.Height()) / 2;

[korli]

Stephan, let me know if you have time to check again with info provided by devheart.

[stippi]

Unfortunately, I don't have much time at all. Would be glad if someone else could review, thanks!

[korli]

OK I applied the patch with the devheart fix in hrev40144. I removed some braces which were unneeded. Tested OK.