Example: 1) Open PV 2) Import a file 3) Save data as .sr 4) Close PV Expected result: PV restores the session, using the data from the saved .sr Actual result: The session is restored but empty since it attempts to restore from the imported file (which PV currently can't do)
Hm, not sure about the expected behaviour. I'd expect the latter, it should restore from the original input file (not from any saved .sr or other files). This is further complicated anyway, since you can save multiple times to different .sr filenames, you can save different chunks of the data to different .sr files, you can (later) export different chunks or the full data to other formats like CSV etc. etc. I'd only restore one of those if the user actually intentionally loaded one of the saved files into a session window.
Well, think of it this way: If you open a file, use "save as" and then save again - which file do you expect to be written to? The file you opened or the file you created using "save as"? I'm used to software using the last-saved file, meaning the newly created file in this case. To prevent that, several software packages offer a "save copy as" option (e.g. gimp). The mechanism described in this bug report would only apply to a complete save, not a partial one.
Currently, Session::save_settings() sets the session's file name to the one associated with the currently loaded device. This means that if an InputFile device is loaded, we can't easily switch that to a SessionFile device without triggering a complete reset and reload of the data.
Workaround added in 73d5a9bbc2f32ed84077ca4e75a125a6b0fc1921, will do for now.