Don't know if this has been requested before (tried searching for it but didn't find anything).
It would be very useful if when closing a window with multiple tabs, sumatrapdf recorded which files were opened and upon restarting the application, sumatrapdf re-opened the last instance opened tabs (much like firefox "Show my windows and tabs from last time").
Proposal: Whenever SumatraPDF is quit through File -> Exit (Ctrl+Q) or whenever the _last_ window is closed, all currently visible tabs are recorded. On reopening, there will be a "Restore previous session" link on the Frequently Read page and in the File menu for restoring these tabs. In addition, there will be a new advanced option for restoring the previous session automatically (defaults to off) which we might eventually expose same as in Firefox.
I think restoring the session should be the default behavior and really the only one unless we start getting complaints. Let's not introduce options and settings until we know there's demand for them.
Adding more complexity is always a possibility. Removing it if we overshot is harder.
Suppose you have document A.pdf open in a single tab and then close the window (exiting SumatraPDF). Now you double-click B.pdf. Would you expect A.pdf to be reopened automatically as well? That would get annoying pretty quickly, as to prevent that, quitting would become a two-step process.
What should happen is a good question but it doesn't imply that the only answer is to make restoring the session optional and off by default.
What should happen if session restoration is enabled and user did Alt-4 with one tab opened? There's an argument for being consistent i.e. if we restore 2 tabs, then we also restore 1 tab.
And if double-clicking on a new document restores 2 tabs, then it should also restore 1 tab.
At the same time, if we decide that it's more likely that in case of Alt-4 with 1 tab followed by double-clicking a new document people expect to only see the new document, then we can special case the "had 1 document opened and now double-clicked".
So the spectrum of possibilities is:
1) What happens for tabs on launching Sumatra without arguments
a) current behavior, we show start page
b) we always restore previous session
c) we make restoring session configurable
a) with default to off
b) with default to on
d) 1c + additional ui to restore session
2) When we do restore the session (1b, 1c) and sumatra is opened as a result of double-clicking on a file or is called with a file as a command-line argument, should we
a) don't restore the session and only open that document
b) restore the session and
a) open the new document in a new tab
b) open the new document in a new window
c) restore the session but special case 1 document in the session in which case we only show the new document
I'm strongly in favor of 1a). I'm strongly opposed to 1c, at least until we have clear signal from users that this is desired. This is based on general principle that we know we can't satisfy everyone's preferences which is why we need to pick the solution that fits 80% of people. I don't want us to automatically reach for advanced settings because they don't really solve a problem (I'm pretty sure a tiny minority of users ever bother with advanced settings).
As to 2), 2ba and 2c seem equally reasonable to me.
1a) means no session restoration whatsoever. So you'd WontFix this?
Suppose you have document A.pdf open in a single tab and then close the window (exiting SumatraPDF). Now you double-click B.pdf. Would you expect A.pdf to be reopened automatically as well? That would get annoying pretty quickly, as to prevent that, quitting would become a two-step process.
If you assume session restoration "on", that would be the expected behaviour, and is I believe how most tabbed apps work (sublime text, firefox, chrome, notepad++, etc.). Whether that option (session restoration) should be configurable I leave that to smarter people :-) (personally I would always use it with "on" but I can totally see why other people would rather have it "off").
@kjk do you disagree in terms of UX with Firefox (and I believe Chrome's also) behaviour towards session restoration?
From what I gather (and am used to - not arguing it's the best though, just what I've grown used to) is that in situation 1) you may have two results depending on whether there is already an instance running (assuming your using tabs), i.e.:
Regarding situation 2, if sumatra is opened by double-clicking a file, the same "algorithm" should be applied, i.e.:
The "session" that's remembered is always the last instance that was closed.
Restore previous session has been suggested by several people in the past (including myself), I think many people will find it useful. I would suggest the following options:
1) a minimalist solution - record all visible tabs on last window closure and add a "Restore previous session" item to the File menu as Zeniko suggested. That's it. This will solve all problems and will not require any configuration. The user can then decide whether they want to restore the session or not.
2) slightly more complex - as above, but in addition when Sumatra starts with no arguments, restore session automatically. If Sumatra is started by double clicking a file, do not restore the session.
I would favour option 1. It is simple, does not introduce configurable options, does not annoy the user with unwanted open tabs and yet provides the user with a possibility to restore session with a single click.
Sorry, I meant 1b).
In other words: my preferred solution is what Chrome does i.e. automatic restoration of previous state. It also happens to be the simplest in terms of effort needed to implement.
For reference: Chrome does 1c), Firefox 1d), and IIRC both have have opt-in session restoration.
I'm opposed to 1b) since that will be the most difficult to get right. Consider: Double-click A.pdf, read it, close the window, delete it, start SumatraPDF. Do you want to show an error page or add another special case to your list?
So are you ok with 1cb i.e. make session restoration configurable via advanced settings and be it on by default?
What happens when we try to restore file that doesn't exist anymore is orthogonal to this and I think we should silently ignore it (e.g. by doing file existence check on files to be restored, so that we don't have to complicate the existing 'open file' code logic).
I'd rather do 1ca), unless you're willing to do a quick 3.1.1 changing the default once common users start getting annoyed enough that they want to turn it off. That'd however also be the users not comfortable with editing advanced options...
IOW: I doubt that 1cb) would pass the "Grandma test" which is likely why Chrome indeed does 1ca) and Firefox 1da).
(As for missing files: Silently dropping them also seems like the wrong thing to do, as in an extensive reading session the file missing error page is an indication to the user that a file which was still needed got accidentally (re)moved.)
Yes, I'm ok with making an update to change the default to off if it turns out people don't like it but at this moment I don't see why people would object to that. We'll get initial feedback from pre-release builds.
As to deleted file case: I don't care that much either way because it's an edge case that will happen once in a blue moon, but I don't see the point of showing an error message that the user can't do anything about and is a direct result of actions that he presumably just took.
Deleted file case may be quite common when people read pdf files downloaded into windows temp directory. These files will be deleted automatically when Sumatra is closed.
Button to restore all recently open/closed, and advanced option to set number. Button goes to start page, to the right of "open a document", and also near recent files, for when some files are already opened and you need to restore, when you open file by double click in explorer, and need previous session back. Also, idk if recent and frequent files are separate, but they should be for this option to work. And when file is deleted, still open tab, but with "file not found" message like browsers do for page not found
For what it's worth I'd like no history to be retained by default, with session restore being a configurable option just like "Remember opened files".
Thanks for the issues, I really need this feature.
It is quite painful to open all of my document one by one after closing it.
(Chrome and Foxit Reader have such this features in their settings)
Any progress with this?
I have not dug into the code of how Sumatra handles file paths and recent documents, put could that same procedure not be used for storing "recent documents" of each session upon exit? hen simply have a toolbar button to restore.
Then again that may cause issues for those who don't want their history to be remembered.
Well, SumatraPDF ought to be able to have a general "private" feature that allows the program to track nothing. No previously used file list, no tab restoration, nothing. It should be one option rather than having to hunt down every possible non-private option.
I don't know whether to raise a separate issue but as it comes under this feature let's put it here.
Working with a large tutorial where it's extremely convenient to operate multiple windows of the same document in a session. Now that MS insists on rebooting frequently, there's a time factor in opening the page positions back again manually
There has to be more than one FilePath entry for the same FilePath. Sumatra opens different documents beautifully, but it's a little awkward making several filecopies of the same tutorial for it to work.as advertised.
Thanks for the fantastic program! :)
This has been implemented for a while.
And how to use the feature?
@qywx: Presumably, they would have to make a new release of SumatraPDF. And it's been awhile since they've made a release.
Or you could download and compile it yourself.
@qywx, @NicolBolas: Or y'all could try prereleases from https://www.sumatrapdfreader.org/prerelease.html
@TPS, @kjk, I downloaded the prerelease version and it still doesn't work. If I kill the process (to simulate restarting the PC), it fails to reload everything that was running at the time.
it only works for proper restarts, not killing the process. When windows is about to shutdown it sends a message to all programs before killing them and we use that message to save the state.
@kjk The reason I tried killing the process is because previously (a few days ago) Windows did restart for me and the prerelease version still didn't restore the tabs. So I tested out a process kill as a way to figure out if I had done something wrong or not.
@kjk - couldn't you just save the list of open tabs every time a new tab/document is opened or closed? Then it won't matter whether or not the process is killed nicely or if it dies suddenly.
Doesn't work for me as expected.
Most helpful comment
This has been implemented for a while.