diff options
| author | blasty <blasty@local> | 2026-07-23 23:52:23 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-23 23:52:23 +0200 |
| commit | 976fcb8440242d45565e19897f3ef1164a3c9940 (patch) | |
| tree | 8644a5ac67645c1e9fda822cab3f712469a8c840 /server | |
| parent | launch: sweep a crashed worker's stale DB locks before starting the supervisor (diff) | |
| download | ida-tui-976fcb8440242d45565e19897f3ef1164a3c9940.tar.gz ida-tui-976fcb8440242d45565e19897f3ef1164a3c9940.tar.xz ida-tui-976fcb8440242d45565e19897f3ef1164a3c9940.zip | |
ux: start the analysis server from inside the TUI (no more dead window)
The remaining "long wait with no feedback" was the launcher's _ensure_server: it
started the supervisor and blocked ~10s polling for the port BEFORE the TUI (and
its overlay) existed. Only a one-line stderr message covered it.
Move that wait behind the overlay. The launcher now only does instant checks
(sweep stale locks if the server is down, honor --no-server) and hands the binary
straight to the TUI with ensure_server=True. The TUI's _connect starts the
server itself and narrates it in the loading overlay ("starting analysis
server… (Ns)") before opening/analyzing the binary. idb_open is idempotent, so an
already-open session is still adopted instantly (the launcher no longer needs to
probe sessions).
_ensure_server gained a progress callback so it reports to the overlay instead of
stderr (which would corrupt the TUI screen).
Verified with the server DOWN: chrome + overlay appear within ~0.5s, notes go
"starting analysis server… (0s)" -> "opening echo — analyzing…" ->
"echo — 128 functions…" -> land on main. Pilot suite (db/ensure_server=False path)
green: startup/palette/view_toggle/disasm_nav/search/rename/follow_xrefs/
decomp_nav/mouse/listing_view/continuous_view/func_banners.
Diffstat (limited to 'server')
0 files changed, 0 insertions, 0 deletions
