Add hover effect to minimap button

[Michael]

Currently the buttons in the minimap have no hover effect like alle the other buttons have.

[Michael]

Adds a hover effect to the minimap icons and removes the approximation of the button.

[Michael]

Icons; put in 'binaries\data\mods\public\art\textures\ui\session\icons\minimap'

[Michael]

This patch tries to fix what I mentioned in #823:

1) Get visible border and hover effect like all the other buttons have
2) Get rid of the approximation

Actually 2) was necessary to accomplish 1) because otherwise it would only be possible to make "local hover effects" which is not what we want.

The patch simply checks, if the position of the mouse is outside of the circle of the map (by distance calculation). If it's outside the circle, it calculates the angle between the verticale and the mouse position and then checks, if there is a button. Buttons are at 45°, 135°, 225° and 315°. A deviation of +- 16° is tolerated which works fine for the Buttons I created.

If the mouse is over a button, the Button is fetch and the Message is send to the Button. (special case: hover effect.)

TODO:

• get Tooltips working.
• don't let the Button loose it's hover effect, when it is clicked and mouse is not moved. (compare to behavior of normal buttons)

[Michael]

PS: I also added the other three Icons to the minimap but they are disabled at the moment because no function is implemented.

PPS: In order to get the Patch running, you have to copy the images of the .zip-file to 'binaries\data\mods\public\art\textures\ui\session\icons\minimap'.

[historic_bruno]

Am I correct that the underlying problem is having non-rectangular buttons in the UI, when it only supports rectangular buttons? If so, the patch is a rather awful way of solving that, it would be better to extend the engine to support arbitrary button shapes (not easy, but far more useful in the long run).

One idea tossed around in the past was to allow defining buttons with a set of coordinates, that probably wouldn't be harder than having limited hardcoded shapes (rect, triangle, circle, etc.). I was looking at that years ago but got hung up on extending the GUI XML parser, with only little knowledge of the engine at the time.

[Michael]

Yeah, your right. This is rather a hack than a patch. ;)

[Michael]

More generic version with image transparency mask but still WIP.

[Michael]

I added a more generic attempt which should support buttons with non-rectangular shape (when it's ready).

You should be able to set an flag as a attribute of a button ("masked"). If this flag is true, the sprite used for the button should be used as a mask. If an area is transparent the button should not be triggered if the user clicks there.

I attached a WIP patch. The most importent part is missing.

Could anyone give me a hint how I can check in an efficient way if a pixel is transparent in the buttons sprite? (See CButton::MouseOver())

[Josh]

I don't think it would be terribly easy to implement it by testing transparency because there is no transparent or not, it's all about how transparent it is (10%, 50%, 90%?).

[Michael]

That's true, but I think normally this would only affect a few pixels (the border of the button because there is a shadowor something similar).

If you want exact control, the "masked" attribute can be changed to "sprite_masked". Then it could be tested for black pixels and they will define the shape of the button. All other pixels would be ignored.

I think this would be easier for people to use than your idea with the function (because you don't have to know how to define the function).

[Erik Johansson]

Would it be possible to use vector shapes to define button shapes? Or would that be even harder to compute?

[JoshuaJB]

In 14819:

Fix hover effect not regenerating after mousedown events, minor GUI code cleanup, and fix #2414

[Josh]

Thanks for the patches boeseRaupe. Although no code was directly shared, they helped me see new ways to solve the problem.

[Michael]

Replying to Josh:

Thanks for the patches boeseRaupe. Although no code was directly shared, they helped me see new ways to solve the problem.

:)

[elexis]

In 20601:

Fix idle worker button mess.

rP14819 mimicked the sprite_over button functionality which exists as a proper property since rP9.
rP17674 mimicked the sprite_disable and enabled button functionality.
The button now shows the proper highlight sprite if the button became enabled without one of the prior mouseover events being sent.
Removes duplicate hardcoded filenames and unneeded globals, functions and conditions.

Refs #2414, #3736
Differential Revision:
Patch By: temple