Cleanup and setup of drop down widget

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.
This commit is contained in:
2024-05-20 22:05:52 -04:00
parent cdfc3d65bb
commit e5be246d30
23 changed files with 23871 additions and 411 deletions

View File

@ -68,7 +68,7 @@ array_init_reserve :: proc
result.header = cast( ^ArrayHeader(Type)) raw_mem
result.backing = allocator
// result.dbg_name = dbg_name
result.dbg_name = dbg_name
result.fixed_cap = fixed_cap
result.capacity = capacity
result.data = cast( [^]Type ) (cast( [^]ArrayHeader(Type)) result.header)[ 1:]
@ -123,10 +123,6 @@ array_append_slice :: proc( using self : ^Array( $ Type ), items : []Type ) -> A
}
}
// Note(Ed) : Original code from gencpp
// libc.memcpy( ptr_offset(data, num), raw_data(items), len(items) * size_of(Type) )
// TODO(Ed) : VERIFY VIA DEBUG THIS COPY IS FINE.
target := ptr_offset( data, num )
copy( slice_ptr(target, int(capacity - num)), items )

View File

@ -214,6 +214,15 @@ pressed :: proc {
push :: proc {
stack_push,
stack_allocator_push,
ui_layout_push_layout,
ui_layout_push_combo,
ui_style_push_style,
ui_style_push_combo,
ui_theme_push_via_proc,
ui_theme_push_via_theme,
}
rotor3 :: proc {
@ -242,6 +251,19 @@ inverse_sqrt :: proc {
inverse_sqrt_f32,
}
scope :: proc {
ui_layout_scope_via_layout,
ui_layout_scope_via_combo,
ui_style_scope_via_style,
ui_style_scope_via_combo,
ui_theme_scope_via_layout_style,
ui_theme_scope_via_combos,
ui_theme_scope_via_proc,
ui_theme_scope_via_theme,
}
sub :: proc {
sub_point3,
sub_range2,
@ -302,12 +324,12 @@ ui_floating :: proc {
ui_layout_push :: proc {
ui_layout_push_layout,
ui_layout_push_theme,
ui_layout_push_combo,
}
ui_layout :: proc {
ui_layout_via_layout,
ui_layout_via_combo,
ui_layout_scope_via_layout,
ui_layout_scope_via_combo,
}
ui_style_push :: proc {
@ -315,15 +337,20 @@ ui_style_push :: proc {
ui_style_push_combo,
}
ui_style :: proc {
ui_style_via_style,
ui_style_via_combo,
ui_style_scope :: proc {
ui_style_scope_via_style,
ui_style_scope_via_combo,
}
ui_theme :: proc {
ui_theme_via_layout_style,
ui_theme_via_combos,
ui_theme_via_theme,
ui_theme_push :: proc {
ui_theme_push_via_proc,
ui_theme_push_via_theme,
}
ui_theme_scope :: proc {
ui_theme_scope_via_layout_style,
ui_theme_scope_via_combos,
ui_theme_scope_via_theme,
}
wedge :: proc {

View File

@ -1,13 +1,12 @@
/*
This is a quick and dirty string table.
IT uses the HMapZPL for the hashtable of strings, and the string's content is stored in a dedicated slab.
Future Plans (IF needed for performance):
The goal is to eventually swap out the slab with possilby a dedicated growing vmem arena for the strings.
The table would be swapped with a table stored in the general slab and uses either linear probing or open addressing
String Intering Table using its own dedicated slab & chained hashtable
If linear probing, the hash node list per table bucket is store with the strigns in the same arena.
If open addressing, we just keep the open addressed array of node slots in the general slab (but hopefully better perf)
TODO(Ed): Move the string cache to its own virtual arena?
Its going to be used heavily and we can better utilize memory that way.
The arena can deal with alignment just fine or we can pad in a min amount per string.
*/
package sectr
@ -19,6 +18,10 @@ import "core:strings"
StringKey :: distinct u64
RunesCached :: []rune
// TODO(Ed): There doesn't seem to be a need for caching the runes.
// It seems like no one has had a bottleneck just iterating through the code points on demand when needed.
// So we should problably scrap storing them that way.
StrRunesPair :: struct {
str : string,
runes : []rune,
@ -36,9 +39,10 @@ str_cache_init :: proc( /*allocator : Allocator*/ ) -> ( cache : StringCache ) {
policy : SlabPolicy
policy_ptr := & policy
push( policy_ptr, SlabSizeClass { 64 * Kilobyte, 16, alignment })
push( policy_ptr, SlabSizeClass { 64 * Kilobyte, 32, alignment })
push( policy_ptr, SlabSizeClass { 64 * Kilobyte, 64, alignment })
// push( policy_ptr, SlabSizeClass { 64 * Kilobyte, 8, alignment })
// push( policy_ptr, SlabSizeClass { 64 * Kilobyte, 16, alignment })
push( policy_ptr, SlabSizeClass { 128 * Kilobyte, 32, alignment })
push( policy_ptr, SlabSizeClass { 128 * Kilobyte, 64, alignment })
push( policy_ptr, SlabSizeClass { 64 * Kilobyte, 128, alignment })
push( policy_ptr, SlabSizeClass { 64 * Kilobyte, 256, alignment })
push( policy_ptr, SlabSizeClass { 64 * Kilobyte, 512, alignment })
@ -69,9 +73,7 @@ str_cache_init :: proc( /*allocator : Allocator*/ ) -> ( cache : StringCache ) {
str_intern_key :: #force_inline proc( content : string ) -> StringKey { return cast(StringKey) crc32( transmute([]byte) content ) }
str_intern_lookup :: #force_inline proc( key : StringKey ) -> (^StrRunesPair) { return zpl_hmap_get( & get_state().string_cache.table, transmute(u64) key ) }
str_intern :: proc(
content : string
) -> StrRunesPair
str_intern :: proc( content : string ) -> StrRunesPair
{
// profile(#procedure)
cache := & get_state().string_cache
@ -110,6 +112,10 @@ str_intern :: proc(
return (result ^)
}
str_intern_fmt :: #force_inline proc( format : string, args : ..any, allocator := context.allocator ) -> StrRunesPair {
return str_intern(str_fmt_alloc(format, args, allocator = allocator))
}
// runes_intern :: proc( content : []rune ) -> StrRunesPair
// {
// cache := get_state().string_cache