This should be seen as the final form of D2313 / rP23005.
That diff made it so that settings referred to member variables instead of being their own thing.
It had 2 major downsides still:
- C++ values could be updated without triggering messages to JS code (potential bug)
- Little flexibility on the behaviour when a setting changes from JS, requiring either:
- hardcoding (e.g. 'size', or worse 'hotkey' in rP22845)
- listening to messages and forwarding.
This addresses these two, by making IGUISetting more of a proper interface, thus making it possible to make derived objects sanely (see D3814).
The main drawback is that the wrapped members are slightly more verbose to use in some cases.
Other impacts:
- The game used the string-settings, via GetSetting and SetSetting, as virtual dispatch of sorts, which was rather convenient. Thankfully:
- We can cast the GUI object to the correct object type (tooltip, radio buttons) safely enough.
- The setting exists on IGUIObject and thus can be 'promoted' to an actual method. We in fact had some getters already doing it. Sometimes combined with the above.
- There are still a few cases of direct string setting, but these seem _ok_.
- It moves a few members elsewhere, e.g. TextOwner now gets its own member variable settings.
- In general this is looking somewhat more like a light entity-component-system (light). This diff doesn't take it there.
This also changes FromJSValVector to clear the vector being passed in, to match the destructive behaviour of this class of functions (and work around a bug, here).
TODO:
I think 'hotkey' & other settings with hardcoded effects should get IGUISetting specialisations insteadTooltips need special handlingThis removes tooltip Icons, as they completely broke my interface, and they seem relatively unused. I'll push another diff specifically on this.Fix radio buttonsTest things out, I have a weird bug in the player assignemnt dropdown.