ed/raddebugger
1
0
Fork 0
mirror of https://github.com/Ed94/raddebugger.git synced 2026-06-18 01:52:22 -07:00
Code Issues Packages Projects Releases Wiki Activity

notes

Browse Source
This commit is contained in:
Ryan Fleury
2024-09-16 17:54:53 -07:00
parent cff6222863
commit fa64116048
1 changed files with 16 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/raddbg/raddbg_main.c
+16 -15
View File
@@ -4,22 +4,10 @@
////////////////////////////////
//~ rjf: Frontend/UI Pass Tasks
//
// [ ] ensure "prefer_disasm" is calculated correctly - disassembly-focused
// stepping
//
// [ ] empty user file causing failure to launch
//
// [ ] frontend entities vs. engine entities
// - currently, the engine has entities like "watch", and the frontend
// has entities like "windows", "panels", and "views".
// - because "watch" entities ideally have a hierarchical relationship
// with windows, panels, and views (enabling things like drag/drop
// from watch window -> tab, or tab -> watch window, trivially), it
// would be much better if all entities could collapse into engine
// entities.
// - now, the frontend requires various specialized resources for things
// like windows, so what I am thinking is that the engine just controls
// all of the stateful windows/panel/view/watch mechanisms, and then
// the frontend pure-functionally queries stuff like os/r handles
// on-demand, and then prunes them, immediate-mode cache style.
//
// [ ] transient view timeout releasing
//
// [ ] save view column pcts; generalize to being a first-class thing in
@@ -478,6 +466,19 @@
// commands can just be a spec * regs, and then the push-command API can
// just have ways of overriding regs values explicitly, when the codepath
// needs to be opinionated about which things are affected by which commands
// [x] frontend entities vs. engine entities
// - currently, the engine has entities like "watch", and the frontend
// has entities like "windows", "panels", and "views".
// - because "watch" entities ideally have a hierarchical relationship
// with windows, panels, and views (enabling things like drag/drop
// from watch window -> tab, or tab -> watch window, trivially), it
// would be much better if all entities could collapse into engine
// entities.
// - now, the frontend requires various specialized resources for things
// like windows, so what I am thinking is that the engine just controls
// all of the stateful windows/panel/view/watch mechanisms, and then
// the frontend pure-functionally queries stuff like os/r handles
// on-demand, and then prunes them, immediate-mode cache style.
////////////////////////////////
//~ rjf: Build Options