sourcehold / Sourcehold

Open source re-implementation of Stronghold 1
MIT License
253 stars 23 forks source link

Make ingame UI alive #70

Open apodrugin opened 3 years ago

apodrugin commented 3 years ago

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:

skrax commented 3 years ago

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 commented 3 years ago

I guess you propose making Widgets work with STL containers and ?

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 think a templated event callback structure could be useful in general.

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).