Per-source configuration files: where they live, what they persist, and how the chooser and the Configurations dialog use them. Martino Ferrari Sessions and settings

udpscope stores named sessions — configurations — per source, so reopening a source gives you the scope you closed, and one source can hold several arrangements for different experiments. There is no global preferences file: the session is the settings.

How to reach it

Nothing to open — the file is written as you work. Its path is in the About dialog, and the directory is $XDG_CONFIG_HOME/udpscope, or ~/.config/udpscope when that is unset. Each source has a directory <host>_<port>/ holding one <name>.toml per configuration and an active file naming the one it is on.

Configurations

Configurations… in the menu lists the running source's configurations: click a row to open it, × to delete it, or type a name and a note and press Save this session to keep the current arrangement under a new one. Opening a configuration saves the current session first, so switching never loses what it switches from.

The startup chooser (start with no --server) lists one row per configuration, with its note and its settings, so two arrangements of one source are told apart before they open.

A configuration also carries the settings that can only be decided when the buffers are allocated: the samples per signal (--buffer-samples), relative time, and the packet capture's ring size. Opening a configuration from the chooser applies all three; switching inside a running app applies the rest and says in the status line that these take effect on the next start.

The chooser's form sets the first two for a new host, and its pencil button edits them on an existing configuration — along with the name and the note. Renaming a configuration, or editing the address it points at, moves it: the old file is removed rather than left behind.

Worth knowing

What a configuration persists: the time window, the rows and each row's slot signals, the calibration, the trace colours, which signals were enabled, the math channels with their graphs, the measurements — and the startup settings: samples per signal, relative time and the packet capture's ring size.

Signal identity is the name throughout, because a new CONFIG renumbers the channels.

A file written by a run against a source whose streamer was down would name no signals at all, so such a run does not write: a configured session is never overwritten by a run that configured nothing. (The chooser hides such a file for the same reason.)

The multicast group and the interface live inside the file, because its name cannot carry them. A file from an older build has neither key and loads as unicast on the default route.

The chooser lists only configurations that name at least one signal, which is what keeps it the sessions you configured rather than every port you have ever tested against.

Deleting a configuration is a supported way to start over; the chooser's × and the dialog's do exactly that.

A session from before configurations existed is imported once as the configuration default, and the old file is kept beside the directory as <host>_<port>.toml.imported.
Example

Connect to 127.0.0.1:8000, drop three signals on row 1, set a 2 s window, and save the session as bench with a note. ~/.config/udpscope/127.0.0.1_8000/bench.toml now holds window_s=2 comment="…" with signals = ["sine", "ramp", "noise", ""], and the next run reports layout loaded from …/127.0.0.1_8000/bench.toml with those signals already acquired.