From fa64116048029343b5df12d6d64b50a206b2c59e Mon Sep 17 00:00:00 2001 From: Ryan Fleury Date: Mon, 16 Sep 2024 17:54:53 -0700 Subject: [PATCH] notes --- src/raddbg/raddbg_main.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/src/raddbg/raddbg_main.c b/src/raddbg/raddbg_main.c index 20b93ee3..3d9d5f23 100644 --- a/src/raddbg/raddbg_main.c +++ b/src/raddbg/raddbg_main.c @@ -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