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 
  the closing).
- Check the .conf file's content.
- Optionally start 'pulseview -D' again, omitting the -d device spec, 
  exclusively using the .conf file's content.