Anything considered static can be aggregated into a single VArena. We don't have to worry about ever releasing its memory or it growing "too large". All memory here must be fixed sized.
Conservative persistent memory can grow on demand but we would perfer if it could be trimmed or released when no longer dealing with heavy scenarios. Persistent memory should use a slab allocator that is backed by a virtual address space pool allocator instead of pools allocating from a single varena. Chained Arenas can source thier chunks of vmem from the slab which can be utilized for scratch memory. Fonts should be loaded from VSlab. The string cache should use a dedicated varena with 16-byte alignment. All conservative memory should be trimmable by a wipe command which should free all unused blocks. Each block should be a single OS aware reserve of vmem.
The Frame can possilby stay as a single varena with scratch allocation utilized on demand. Although it may be more viable for chained varenas to be derived from the main varena via a slab or pool interface. Frame memory should be trimmable on command which should release its committed vmem to its initial value. A dedicated transient varena should not exist. It should be removed when possible. File mappings for now can use a dedicated varena made on demand with a capped reserve size of 4 meg. Any file exceeding this needs the host to support virtual memory mapped I/O for files. The codebase db will use sqlite for the file I/O abstraction.
Host might only need to track the first persistent block of vmem, and the rest can be handled by the client (including wrapping that vmem up in a varena). Hot-reload only needs persistent vmem's ref restored on the client module's side. All other references can be resolved from there.
Still need to figure out input event consumption, I don't want to do it with the event ring.
I would like to setup input binding layers and then have the push/pop input contextes with a set of bindings.
If the bindings are detected it should "consume" that binding from further use for the buffered time period.
This will be really important with how heavily model this app will be.I
I'm enforcing aprintf it as the default formatter.
I changed up the context allocator assignment to reflect how I've been intending to allocation in startup & platform events vs tick.
Tick uses the frame slab's by default with transient on temp. Startup & platform events use the transient by default & for temp, with any use of the persistent allocator being explicit.
Got an initial variant of the drop down widget, not completely set on it..
I put some more time to figuring out how I'm going to be ideomatically constructing the widgets. screen.odin I think its getting pretty close to what it will be like.
I'm ready to start lifting the input box. I'll be adding the constraints when I lift it.
Added the option to toggle the debug text in screenspace
Added the fixes from the ui_layout_children_horizontally for margins to ui_layout_children_vertically
Known issue:
There is a bug with test_whitespace that forced me todo a null check on a box. Not sure why.
It needs to be redone anyway.. (compose it with the h/vboxes instead)
There is some sublime files added in, started to use it.
Renamed KeyboardKey to KeyCode, redid the encoding layout (preemtively getting ready for SDL later as well)
I got the input box working but it has no constraints and needs to be lifted. The scroll box construction does as well.
Moved core ui to its own folder.
Worked on theming (proper light and dark theme)
Began to work on the scroll box widget and input box constructions
I added back a script for flattening the codebase: gen_flattened_codebase.ps1
