Assumption: Users can create an environment in the GUI, which gets stored
and is re-used when the program opens again. Pulseview attempts to open
most recently opened files or re-connect to devices that were connected
and used before (when they are in use when the program closed, not when
their respective tabs were closed before the program closed). The
information is kept across program invocations in the pulseview .conf file.
It appears that the .conf file does not contain enough information to
re-connect to the device. Network and serial connections are known to
not be kept in the current implementation (see bug 882). But USB devices
seem to be affected, too. I would expect to find the essential information
which is required to attach to a device again, like: driver name,
conn= spec, and other internal references. Instead the .conf file appears
to contain what I'd call "display text" that was gathered from the
found device and is presented to users, but which cannot be used to
re-establish that very connection. Compare "ols" the driver name to
"BPv3" the detected variant of supported devices. Or "kingst-la2016"
the driver name to "Kingst" and "LA5016" the detected model.
How to reproduce:
- Start 'pulseview -c', close the tab (CTRL-W), close the app (CTRL-Q).
This shall wipe out any previous configuration.
- Start pulseview with a -d spec (device to connect to, specified on the
command line), or interactively connect to a device. Additionally
passing -D keeps the test execution clean (only the specified device
is probed, and connected to).
- Don't close the tab, but close the application (CTRL-Q, maybe ACK
- Check the .conf file's content.
- Optionally start 'pulseview -D' again, omitting the -d device spec,
exclusively using the .conf file's content.