Another reason I just thought of that this is challenging for users is that most of the documents that are opened from the web are not usually saved locally (at least not immediately). So if a user does want to log off or restart their computer, they must save each file somewhere locally, and then log off or whatever. Then, upon resuming their work, they have to reopen each doc individually. 

That's a lot of work, just to log off.

Yes, it would be nice to have.

Fixed in git master. Thanks for reporting. 

My pleasure. I look forward to this feature getting rolled out to the distros!

https://bugs.launchpad.net/bugs/403960 argue against this change

"

This is a bug report related to usability, please deal with it as such, that is, let us discuss if the behaviour is correct or not before dealing with technical aspects. This bug has been introduced in karmic.

When evince crashes, it offers the option to recover documents at next startup. This option makes a lot of sense if evince is opened from the menus, that is, if there is no file to open. It makes few sense when evince is launched by clicking on an unrelated pdf to open it. There are various reasons for that.

1) evince is a viewer, not an editor like openoffice, so in general it is not so important to "recover" documents. Actually, the word "recover" is plain wrong, since there is nothing to recover at all, because evince is not an editor like openoffice. "open" or "load" is the right word perhaps.

2) evince, differently from e.g. firefox, is not a multi-window and/or multi-tabs application. This is in harmony with the gnome guidelines that suggest just one document per window. Therefore, it has few sense to open an unrelated document when clicking on a different pdf. I consider this the most important reason.

3) if evince crashes on a pdf, chances are it will crash again so recover is not that useful

4) if evince crashes, the user typically will click on the same pdf again to reopen (and eventually discover point 3 above). This currently triggers the "recover document" dialog, and whatever is the user choice, the same document is opened, only once (because evince does not open multiple windows for the same document)

I work with pdfs all day, and evince tends to crash often in recent releases, thus I have good experience with the recover functionality. I personally never found that useful, and found annoying a frequent popup before opening my documents.

I would therefore suggest that the recover documents functionality is either entirely removed or just used when evince is launched from the menus (technically, when there is no document to open in the evince command line).

If not, at least point 4 should be addressed, that is, the recover functionality should not be offered if the only document to recover is the one that is going to be opened. Also, the word "recover" should be changed for something better. Will report upstream later."

Wouldn't it address everybody's concerns if we could do the restore only when opening evince from the menus? After all, openoffice and firefox are multi-document interface applications, while evince is single-document. Opening more than one document when clicking on a single pdf is very strange to my eyes when I put off my developer and geek hat.

If you are not convinced yet, try to imagine if all viewers in gnome did the same: every time your session crashes, what you had opened is recorded. Then next time you open eog, or totem, it asks you if you want to recover the old session. I don't think we have other viewers in the desktop.

Even better would be if firefox reopened the documents opened with external applications because evince is only acting as a "slave" of an MDI application in the case of documents opened from the web. E.g. if you use the acrobat reader plugin (could evince implement a similar functionality??) then your documents are restored when you reopen firefox even if acrobat itself does not recover anything.

On the other hand, even if it is true that one may have many pdf documents opened at session crash, that's also true for source files opened in editors and many other things. In a word, what we are talking about is saving the user session, thing that is currently not done. Evince is having an exceptional behaviour here because it's a SDI application. Firefox and openoffice are MDI so it makes sense to open many documents.

You lost me with the MDI vs. SDI acronyms, but I should chime in as the reporter of this bug. 

For me, this was necessary because I use evince to read the things I find on the web. So, I click on a link in Firefox, it opens evince, and now I've got one document open in evince, and I feel that I can safely close the tab in Firefox that led to it. Next, I do this again and a gain until I have a whole bunch of PDFs open, all of which were hard to find, and which are important to the research I'm doing.

If my computer crashes at this point, I have a mess on my hands, and will lose hours of work. This is very different from the other applications you list above that are SDI because I'm not using those to view things via the web.

As for only doing crash recovery if it's opened from the menu, I'm not sure that's a great solution either because sometimes I forget that I only have one or two documents open when a crash occurs. If that's the case, it's quite nice to be browsing, open a PDF randomly, and have the crash recovery dialog pop up to tell me that evince has done me a favor. If I had to open it via the menu, I'm not sure I would: (1) figure out that that's the system, (2) think to do that after a crash.

Addressing some of your other points above:
1. Recover seems like a fine word to me. It's recovering from a crash after all.
2. I think I addressed above.
3. True, if a PDF is the cause of the crash. In my case this isn't usually the case. Usually, something else crashes evince, and resuming where I left off is a very nice thing.
4. If you're saying that the crash handler won't do much good in the case of a PDF that crashes evince because that PDF will just crash it again, that's a good point, but I'd suggest it be filed as a different bog.

And I agree with the last paragraph of comment 5, but that sounds like another bug too.

Mike: it is very clear to me why you want this feature and how do you use it. What I think is that the feature is implemented in the wrong place, and that there are equally strong cases against this feature. So let me see if we can get to a nice conclusion. I do not have the powers to remove the feature so you should not worry a lot. The developers shall decide and I bet they are inclined not to change things. Perhaps they could decide to set an option for SDI vs. MDI behaviour in evince, and maybe even implement tabs in it.

I am concerned with a "hassle free" and consistent desktop experience and think that the current solution is in the way of different usage patterns than yours (forgive me if I talk like a software engineer, actually I am not in that business but I need to be clear).  

First let me see if I can put problems of the current implementation in clear light, then we can discuss alternative solutions.

But even earlier, a question: are you sure that you can really reopen the session after a computer crash? How is this implemented? Firefox saves files to /tmp, when it closes files are lost. So you are not that safe in closing a tab, since if you close the last tab (e.g. by closing the window) you lose all the pdfs. In case of a computer crash I seriously doubt that evince can restore those. Unless I miss something, the current implementation does not solve your problem.

SDI (single document interface) vs MDI (multiple document interface) is a topic that was discussed a lot when gnome 2.0 was born. This even led to the default behaviour of nautilus called "spatial mode". The idea of SDI is that to a single window corresponds a single piece of data. This is not the case of firefox, openoffice, or emacs: they are MDI programs, so they may have an associated notion of "session".  Evince behaves like an SDI: each window is associated to a pdf file (of course you can change that, but in each moment there is one document per window. So there is no perceivable notion of "session" in evince by itself. 

- You say that you need to recover already opened documents. This is nice but does it feel right to you that you have to click on a random pdf maybe on your desktop, to open a set of unrelated documents? Quite because evince is SDI, clicking on a PDF should have the effect to open that pdf. If a notion of session was intrinsic in evince, it would make more sense to recover other files. But still, this is why I use gedit to open random latex files and kile to work on my papers: each paper is a session, but when I click on a random  latex file I don't want to open all the subdocuments of my last-worked-with paper. This is in general one reason why MDI interfaces are problematic to deal with.


- You say you have this problem with PDFs. But when I develop my small free software project I have this problem with the editor, the terminal and the web browser for documentation. They are even unrelated apps, not linked by a common session. I don't expect that when I open a text file with the same editor after a crash, my previously opened terminal and browser open. But that's the same problem that you have with pdfs! Notice that I have that problem too with pdfs. I am a researcher and open dozens of pdfs from the web, but I have other problems with the current approach.

- In general, all of us lose all their opened windows when a session crashes. Now the restore behaviour is implemented in evince. The same behaviour could be implemented in all applications. Now I realise that the difference is that evince is launched from firefox. But still, many document types can be opened from firefox, including e.g. archives. Adopting the same principle, every time we click on a zip file on the desktop, unrelated archives that we opened using firefox should open!

- As I said above, I seriously doubt that restoring the session would re-open temporary files because they are lost. I see that this can happen if firefox crashes without deleting temporary files, and you don't reboot your computer. But that's the sum of two bugs: 1) firefox crashed and 2) temporary files by their nature are deleted only at reboot. But 2) could change with time and better implementations of the /tmp thing.

- You say "As for only doing crash recovery if it's opened from the menu, I'm not sure that's a great solution either because sometimes I forget that I only have oneor two documents open when a crash occurs. If that's the case, it's quite nice to be browsing, open a PDF randomly, and have the crash recovery dialog pop up". This is where we disagree: for me it is strange, because crashes happen, and they bring away ALL opened windows. When I am back, perhaps doing something else, I click on a pdf to open that pdf. That's the "hassle free" experience I was talking about: be able to predict what the computer is doing. Click on a PDF, open it.

- You say: "3. True, if a PDF is the cause of the crash. In my case this isn't usually the
case. Usually, something else crashes evince, and resuming where I left off is
a very nice thing."
Actually, my experience (perhaps because I work with people who embed images cutted and pasted from OSX in pdfs) is that evince crashes. Then it is completely unuseful to try to recover these pdfs. These are two different use cases that need two opposite solutions. We can not start arguing on which is the most frequent use case. My system is very stable for example, and my session usually does not crash unless I try hibernate or suspend.

SOME POSSIBLE ALTERNATIVE SOLUTIONS

As I said, if we want consistency of desktop applications, we should apply the same principle everywhere. So each SDI application (archive manager, totem, eog to name a few) should pop up questions when start them again to open unrelated files after a crash. This does not make sense to me: then you would have to remember to click on a file (zip, jpg, mov) for each application that you had opened before the crash.

Would you really enjoy a desktop where whenever you click on any file (because most of the current gnome programs are SDI) a question is asked if you want to recover other files? That would get annoying very soon. You are lucky because your use case is to open dozens of pdfs and you want to recover them. But if all applications did that, you probably would NOT want to recover everything. E.g. when you click on a movie depicting your vacations in front of your mother you probably don't want to recover the porn you were watching this morning (it's just a joke but it should render the idea).

Or otherwise, here's what I think:

recovering a (non existing) evince session is not what you are asking for. You are asking for session recovery of your gnome session, specialised to pdf files. I think that, for you, session recovery in general would be even better, e.g. after a crash you would reopen firefox, with eventual wikipedia pages you were reading, whatever editor you are using with all its documents opened, all the pdfs opened (but not because they are related, just because different instances of evince would be reopened), the file manager, and so on. If this is not what you want, it is unclear to me why pdfs are the right thing to restore and e.g. file manager windows are not.

This is highly dependent on your specific use case which may be different than mine. But the general meaning of clicking on a pdf in gnome is "open _that_ pdf".

1) turn evince into an MDI document viewer like firefox, with a notion of session to recover (and notice that firefox now offers a choice of which windows to recover after a crash). This still would not solve the problem of deleted temporary files!

2) create an evince based plugin for firefox, this is a sane approach because what you want is to recover pdfs that you are reading online

3) use already existing session saving mechanisms. I don't know where it ended but gnome had a session saving system and a session saving protocol. The right solution to this bug would rather be evince implementing the session saving protocol. This is because with SDI applications the notion of "session" belongs to the destkop environment, not to single applications: they are "single document interfaces" and have no built-in notion of session. But take a look at the description of the package "gnome-session" which you are probably running, in ubuntu if you run that. It explicitly mentions session saving, so perhaps it can be bended to your needs.

Let us try to reach an agreement. Even if you say that your comment addresses my (2) observation, I really don't see how: the problem here is that when I click on a pdf I want to open that pdf. This patch addresses a very specific use case, but breaks that principle.

The proper fix would be to become a real SDI indeed and implement the request from the bug #583680. Then recovery will become obsolete.

About session support, we do have it, but unfortunately it's broken GNOME-wide.

I disagree Nickolay, the crash recovery is also useful for system crashes, which becoming a proper SDI wouldn't fix.

Vincenzo, to respond to you briefly (what a response!), I think the best solution is to leave it as is, except to give it the functionality introduced in FF3.5, which allows certain tabs to be selected for recovery, thus allowing offending tabs to be closed. If this is a good idea, we should file a bug for it.

I will also say that I would indeed like it if each application would remember where it was when it or the system crashes. I find crashes catastrophic, and I appreciate anything that gets me back to where I was before the crash.

Session support is going to be broken also because there are applications that don't support it, but I think that session recovery should become a priority in gnome, maybe with some discoverable way of deciding what to recover and what not.

Nickolay: does gnome have an usability team? I bet so :) Gnome is where I learned usability from. Couldn't you discuss this issue with them? I think that since you implemented the code, the best thing would be to turn this into a gconf option and then decide what's the default with the usability team. Let me insist that the major problem is that clicking on a PDF is expected to open that pdf and not other ones.

Mike: all of us hate crashes. But you didn't tell me if recovery really works for firefox documents or files are deleted from /tmp. If the case is the latter, perhaps what you (and me, too) really want is an evince firefox plugin or the ability in firefox to reopen NOT ONLY the tabs, but also the dependent applications, maybe selectively by appplication or by file type. 

Wow I don't know where to start. 

Vincenzo: first of all, thanks for the so detailed feedback. 

It seems to me you are assuming the recover dialog is always shown when you open a PDF, I know you are not, of course. 
You said evince crashes a lot for you, please file bug reports for those crashes, if evince doesn't crash you won't have to see the recover dialog anymore :-P 
It seems to me also that you are assuming you have to always accept to recover the session, you can click on the cancel button and only the requested document will be opened. 
It's true that evince is a SDI application, but it behaves internally as an MDI which has advantages and disadvantages, but this is another issue. 
I agree we shouldn't show the dialog when the requested document is the only one to be reopened by session recovering. Note that is not the document what is recovered, but the session. There's a session in evince because it's an MDI app internally. 
One of the disadvantages of such internal behaviour is that when one of the evince window crashes (please, file a bug report) all other opened windows crash too. If you have a lot of documents opened, session recovering is quite useful. 
This is manily thought for evince sessions crashes, not for system crashes, that's why files on /tmp are not an issue. I agree that for system crashes, gnome session managment should do the work. 

I'm not sure about removing this feature, so let's better focus on how to improve it.

Carlos: I filed bug for the crashes indeed. I will doublecheck if some of them is still waiting in ubuntu to get reported "upstream", that is, here.

But still, I am going to see the recovery dialog when for some reason the system crashes. This may be what you want but if I start bugging other viewers such as eog or totem they are going to send me where I deserve :)

What I think is that for implementative reasons, that is, internal MDI, the system is behaving in an odd way. That's just bad. Then why not turning evince into an MDI? Or otherwise, couldn't you just use fork(3) on open to turn evince into an SDI? I was considering to get the source and try this but as I don't know gnome sources I prefer to ask before.

As a last note if files on /tmp are not an issue, the main reason to handle this request, that is, Mike's use case, has not been addressed! 

I see that you are not willing to remove the feature and I do not question that, but couldn't you at least make it into a gconf option and let distributors and eventually end-users decide? Or could you please just raise this with your usability team and hear their opinion?

I will try to avoid bothering you anymore on the issue anyways.

fork(2) of course :)

(In reply to comment #13)
> Carlos: I filed bug for the crashes indeed. I will doublecheck if some of them
> is still waiting in ubuntu to get reported "upstream", that is, here.
> 
> But still, I am going to see the recovery dialog when for some reason the
> system crashes. This may be what you want but if I start bugging other viewers
> such as eog or totem they are going to send me where I deserve :)

hmm, maybe we can just somehow disable the session recovery for system crashes. 

> What I think is that for implementative reasons, that is, internal MDI, the
> system is behaving in an odd way. That's just bad. Then why not turning evince
> into an MDI? Or otherwise, couldn't you just use fork(3) on open to turn evince
> into an SDI? I was considering to get the source and try this but as I don't
> know gnome sources I prefer to ask before.

you don't need to change the code, just build evince without dbus support. I think metadata is the only thing that depends on dbus right now. 

> As a last note if files on /tmp are not an issue, the main reason to handle
> this request, that is, Mike's use case, has not been addressed! 

Right, but I'm talking abnout the current behaviour. 

> I see that you are not willing to remove the feature and I do not question
> that, but couldn't you at least make it into a gconf option and let
> distributors and eventually end-users decide? Or could you please just raise
> this with your usability team and hear their opinion?

Well, I said 'I'm not sure'.

> I will try to avoid bothering you anymore on the issue anyways.
> 

Maybe you got me wrong, your feedback is appreciated and I'm open to disucuss. 

Hmm my words could be easily misunderstood: I don't mean that I thing you are bothered by me. I appreciate the discussion but I mean: hey, if you decide the code should stay there, I can't endlessly discuss until death so I won't do that :) 

You have been keen in implementing the feature on request and to listen to my concerns. I don't know right now why ubuntu builds evince with dbus support but that seems better, what's this metadata you talk about? Why is it important to have dbus support in evince?

Metadata is the per document information saved (window position, zoom level, current page, etc.). This is saved in a single xml file. D-Bus is used to implement single instance application, when there's an evince process running, all new evince processes will send the information through dbus to the first one and they just finish.

I tried evince without dbus support. Please test it thoroughly yourself as it appears to be popping up the document recovery dialog more or less randomly (the recovery code should probably be not even compiled in without dbus). 

As a side note, a good/bad feature is that it allows me to open the same document twice. I rarely feel the need to do that, but when it happens I have to resort to another viewer. But that's not a concern right now, I understand that there are reasons for not doing that.

However it is very neat that killing one evince process does not kill the other ones, so the next question is: with dbus enabled, you already open just one instance for each file, so why not saving the metadata in separate files, as I believe okular does. Nautilus does that for folders. That would eliminate the need of a "server" evince process which introduces this mess. And would eliminate the need for recovery. Another option is to save the metadata using gconf keys.

Right, it's now disabled when evince is compiled without dbus. 

I've just applied another patch to avoid showing the recover dialog when there's only one file to open from the command line and it's the only one to be recovered by the session. 

Nice, thanks.