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:
- C++ values could be updated without triggering messages to JS code (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.
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.
TODO:
- I think 'hotkey' & other settings with hardcoded effects should get IGUISetting specialisations instead
- Tooltips need special handling
- This removes tooltip Icons, as they completely broke my interface, and they seem relatively unused. I'll push another diff specifically on this.
- Fix radio buttons
- Test things out, I have a weird bug in the player assignemnt dropdown.