Ed_
1b32fe916e
Saw that layout really should be separated from the style struct, so went ahead and pulled the trigger... A bunch of other refactors have also been done * Lifted layout out of style, its not separate in UI_Box and in UI_State there is not a UI_LayoutCombo stack. * UI_StyleTheme renamed to UI_StyleCombo * UI_Theme has both UI_StyleCombo & UI_LayoutCombo * Made files for the "project" related code * ui_layout_compute moved to its own file, ui_layout now used for layout related data structures and interfacing * Impovements to horizontal & vertical box impl * UI_Box now keeps track of how many ancestors it has
1.2 KiB
1.2 KiB
UI
Ideal UI_Box processing per-frame
Would be done in this order:
Build Graph Start
- Parent constructed
ui_box_make()- Prepare layout & style
- Construct & process children
- Post-children populated processing
- Auto-layout box
- Process signal from children & depdendent events
ui_signal_from_box(box)- Process state dependent on signal
- ... Eventual Render Pass
Issues:
You want to batch auto-layout to be deferred to the end of the construction for the state graph of the frame.
Rendering should be handled outside of the update tick asynchronously (at worst case).
StyleCombo and LayoutCombos are not stored in UI_Box (it would b N * (Style + Layout) per box of memory where N is the number of entries in a combo (right now there is 4) )
A layout must be choosen before auto-layout occurs and rn the convention is that layout & style are choosen at the end of a signal since it depends on the box's state from the signal.
Adjusted order:
- Parent constructed
- Prepare layout & style beforehand
ui_box_make()ui_signal_from_box(box)- Construct & process children
- Post-children populated processing
- ... Build Graph End
- Auto-Layout Pass
- Eventual Render Pass