Repository navigation
Make ingame UI alive #70
Description
Currently part of the UI is not rendered at all. Corresponding actions are not performed.
Here is an action plan which allows make ingame UI more or less alive:
- Refactor Widget class and related subclasses
-- Merge Container class functionality with Widget class to simplify widget hierarchies management.
-- Add events processing to Widget class. This will allow us properly route events to subwidgets.
-- Clean up Update methods in all widgets.
-- Get rid of StaticElement. Use Widget subclass instead.
-- Make Button widget more generic so it can be used with different background images. - Implement game menu (info, revert, etc.) rendering.
- Implement game menu actions handling (show all necessary dialogs with minimal implementation).
- Implement buildings selection menu rendering (render all buildings types, no animations).
- Implement switching between tabs in buildings menu.
Activity
skrax commentedon Mar 16, 2021
Merge Container class functionality with Widget class to simplify widget hierarchies management
I guess you propose making Widgets work with STL containers and <algorithm> ?
Add events processing to Widget class. This will allow us properly route events to subwidgets
I think a templated event callback structure could be useful in general.
apodrugin commentedon Mar 17, 2021
Yes. Currently Container class holds vector of Widgets and it is used to create widgets hierarchies. So basically my idea is to move subwidgets management to Widget class and make it available for all subclasses. I want to add reference to parent widget and list of child widgets to Widget class. This will allow us to create traversable widgets trees. Actually this approach is used in UIKit. It simplifies a lot of things (for example, you may create new kind of widgets without creating subclasses, perform subwidgets layout relatively to parent widget, etc).
Container class is also responsible for two kinds of automatic layout (horizontal and vertical). My idea is to move this logic to separate class - StackWidget.
I will try to preserve this approach, but I think that every widget is interested in touch, mouse and keyboard events handling (probably except static text and static images/icons).