Add gesture communicator

[esainane]

This is a menu that can be bound to a key, such as BACKQUOTE. When opened, the user is presented with a series of radial menus which select predefined text for a marker to be added at the initial point. Inspired by DotA's hot chat wheel, but as Zero-K has much more we want to say, why not take inspiration from the existing and rather impressive gesture build widget?

The exact predefined text is open for discussion and/or total bikeshedding. I'm of two minds about some, especially those in the six-o-clock submenu. Ultimately, I left them in, as I feel having markers more descriptive than "omg" or "lobster", which now also take less effort to send, might help to nudge people into being slightly more helpful in very common situations. Maybe. One can hope.

This necessarily involves exposing the real MarkerAddPoint to widgets, which is also something to consider.

Since there would have been extremely high overlap with the gesture build widget, the gesture build widget has been refactored into an API widget that provides the overwhelming majority of common code and takes callbacks. This also means a better functional separation of concerns - gui_gesture_build and gui_gesture_comms are absolutely tiny compared to the previous gui_chili_gesture_menu, and api_gesture_menu is slightly more readable too.

Included are a few bug fixes and cleanups for the gesture build menu, which can be turned into a separate PR if desired.

Wishlist:

• Find a nicer way of initializing values of the default instance options
• Work out whatever was supposed to happen with determining whether the minimap location was left or right, and either fix or remove it as appropriate
• Turn right-click-drag options into a radio menu, with each gesture menu instance adding their own entry ... somehow, eventually
• Have some sort of receiving widget that can optionally translate the predefined text into each player's native language ... somehow, eventually

[sprunk]

This necessarily involves exposing the real MarkerAddPoint to widgets, which is also something to consider. (...) Have some sort of receiving widget that can optionally translate the predefined text into each player's native language

Replace Spring.MarkerAddPoint(x, y, z, "Attack here!") with Spring.SendLuaUIMsg("ChatWheel attack_msg" .. x .. y .. z) (possibly with some math.floor or even VFS.PackF32 applied to the numbers). Then, add widget:RecvLuaMsg(msg, playerID) which parses the message and calls MarkerAddPoint locally with the relevant player's ID as the 6?th param (which makes it appear as if that player made the marker) and WG.Translate("attack_msg") as the message. See https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaUI/Widgets/camera_lockcamera.lua for an example. Decoupling the interface from MarkerAddPoint also allows the markers to eventually replaced with something fancy (eg. could be hooked into https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaUI/Widgets/gui_custom_markers.lua )

[sprunk]

Related #3104

[sprunk]

nitpick: comms could be interpreted as commanders

[GoogleFrog]

Agreed, and I don't think Gesture Menus needs to be part of the path.

[GoogleFrog]

I agree with Sprunk. Another benefit of SendLuaUIMsg is that it would slot easily into the localisation system.

I don't know where the menu should go in hotkeys. Do you have any good suggestions that don't conflict? The gesture menu worked because Licho was personally fine with not having access to custom formations when constructors are selected.

I think the texts are generally too long.

[esainane]

Replace Spring.MarkerAddPoint(x, y, z, "Attack here!") with Spring.SendLuaUIMsg("ChatWheel attack_msg" .. x .. y .. z) [...]

Sounds like the moonshots are more achievable than I initially thought! That's still probably going to be shelved for the immediate future, though that should make for a really nice extension.

I don't know where the menu should go in hotkeys. Do you have any good suggestions that don't conflict?

Personally, I've been using BACKQUOTE, since I tend to use \ as the drawing key.

It might be possible to use BACKQUOTE for both, with a short keypress opening the menu, and a held key used for drawing. That might fit with the existing "quickly communicate" semantics. I'm not sure if there's an easy way to accomplish this with the current framework.

I think the texts are generally too long.

I agree. Do you have a more palatable set of options in mind?

[GoogleFrog]

• I do not want to pull the Spring.MarkerAddPoint version.
• You could try a backquote tap. All the other backquote uses involve holding the key so it might work.
• I expect writing texts in the configuration while working on the widget directly would be faster than communicating changes.

[GoogleFrog]

Does it PR work entirely except that it sends engine markers instead of as-yet unimplemented lua markers?

[sprunk]

I pulled the first 5 commits that just apply some bugfixes.
I left extracting the API out but am planning to also pull it shortly (bigger change).
I don't plan on touching the markers part yet.

[esainane]

@GoogleFrog The PR is in a fairly stable state and is something that I've been using for a while. gui_gesture_comms as a whole is under 100 lines total, and the PerformAction callback only 5, so swapping out the action for something that uses a system more featureful than engine markers should be very straightforward, once such a system is available.

[GoogleFrog]

Is the behaviour of gesture build menu unchanged?

[esainane]

There should be two user facing changes:

• People are able to configure a longer icon distance if they so choose. The default is unchanged.
• Previously, if the item selected at the end of a gesture was not a hub, the flash tracing the gesture would be off-center. I've fixed this so that the flash always traces to the end. I consider the old behaviour a bug.

[Licho1]

Can there be a bad interaction with gesture build menu?

[GoogleFrog]

Part of this PR is that it makes a generic gesture system that is then used by the communicator and the gesture menu. As far as I know there is no control overlap because the communicator is opened with a hotkey.

[sprunk]

People are able to configure a longer icon distance if they so choose. The default is unchanged.

That was among the other fixes and is already in master.

[GoogleFrog]

There is a standalone ping menu by a high mana BAR guy.

[sprunk]

The standalone ping menu seems to be fairly crap though, it's still GL3 and only has one layer.

[GoogleFrog]

Yes, just worth noting.