added loading screen

README.md

@@ -44,6 +44,20 @@ it that reads as a hang. Each allocation also names itself on stderr
 (`[udpscope] buffer allocated: 4 channels, 839 s span, 74 ms`), so a run that prints a column of them
 is a re-plan that should have been coalesced.
 
+**And a loading window covers the gap the status line cannot.** That notice only exists once there is
+a window to put it in, and a run started from the **source chooser** has none: the chooser destroys
+its own window the moment a row is clicked, and what follows --- the first allocation, the wait for
+the stream's CONFIG or the read of a recording, and then the whole UI being built --- runs with no
+main loop at all. The screen was simply empty for it, which at a multi-gigabyte buffer is the ten
+seconds that read as "the dialog disappeared and nothing happened". A small window now stands in that
+gap, raised before the buffer is planned and taken down only once the real window has been presented.
+It names the wait in words --- `Connecting to 127.0.0.1:8000` over `planning the 4000 MB sample
+buffer`, or `Opening rt.npy` over `reading the recording` --- because nothing can animate while the
+work runs: its spinner is frozen for the duration, a progress bar would have nothing honest to show,
+and it carries no close button for an application that could not yet service one. A source named with
+`--server` or a file named with `--open` never sees it: those runs never had a window to lose, and the
+notice after the present is the right place for them.
+
 Every CONFIG is dumped to stderr once -- publish mode and, per signal, its name,
 element count, rate, time mode and time-signal index -- because a signal that
 refuses to plot is almost always a signal the stream described in an unexpected