ed/SectrPrototype
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Large refactor of the entire codebase

Browse Source 
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
This commit is contained in:
Edward R. Gonzalez
2024-05-11 22:38:05 -04:00
parent 6a4f7ac6de
commit 1b32fe916e
22 changed files with 1023 additions and 762 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
Readme.md
View File

@ -21,24 +21,34 @@ The dependencies are:
* Odin repo's base, core, and vendor(raylib) libaries
* An ini parser
The client(sectr) module's organization is relatively flat due to the nature of odin's module suste, not allowing for cyclic dependencies across modules, and modules can only be in one directory.
The client(sectr) module's organization is relatively flat due to the nature of odin's compiler, not allowing for cyclic dependencies across modules, and modules can only be in one directory.
This makes it difficult to unflatten, not something organic todo in a prototype...
Even so the notatble groups are:
Even so the notable groups are:
* API : Provides the overarching interface of the app's general behavior. Host uses this to provide the client its necessary data and exection env.
* Has the following definitions: startup, shutdown, reload, tick, clean_frame
* Env : Core Memory & State definition + orchestration
* Grime : Name speaks for itself, stuff not directly related to the target features to iterate upon for the prototype.
* Defining dependency aliases or procedure overload tables, rolling own allocator, data structures, etc.
* Font Provider : Manages fonts.
* When loading fonts, the provider currently uses raylib to generate bitmap glyth sheets for a range of font sizes at once.
* Goal is to eventually render using SDF shaders.
* Input : Standard input pooling and related features. Platform abstracted via raylib for now.
* Input : All human input related features
* Base input features (polling & related) are platform abstracted from raylib
* Input Events
* Parser : AST generation, editing, and serialization. A 1/3 of this prototype will most likely be this alone.
* UI : AST visualzation & editing, backend visualization, project organizationa via workspaces (2d cavnases)
* Project : Encpasulation of user config/state separate from persistent app config/state as a 'project'
* Manages the codebase (program model database)
* Manages workspaces : View compositions of the codebase
* UI : Core graphic user interface framework, AST visualzation & editing, backend visualization
* Will most likely be the bulk of this prototype.
* PIMGUI (Persistent Immediate Mode User Interface)
* Auto-layout with heavy procedural generation of box widgets
* Auto-layout
* Supports heavy procedural generation of box widgets
Due to the nature of the prototype there are 'sub-groups' such as the codebase being its own ordeal as well as the workspace.
They'll be elaborated in their own documentation
There is some unused code in `code/__imgui_raddbg`. Its a partial translation of some data structures from raddbg's ui.
@ -47,3 +57,4 @@ There is some unused code in `code/__imgui_raddbg`. Its a partial translation of
![img](docs/assets/sectr_host_2024-03-09_04-30-27.png)
![img](docs/assets/sectr_host_2024-05-04_12-29-39.png)
![img](docs/assets/Code_2024-05-04_12-55-53.png)
![img](docs/assets/sectr_host_2024-05-11_22-34-15.png)