GNOME Bugzilla – Bug 682917
Evince should show filename of file that failed to open (with 1-line patch)
Last modified: 2013-04-24 04:57:59 UTC
Here's the scenario I run into every couple of weeks: I shut down the computer/it crashes/power is turned off. I happened to have 20+ PDF documents open, most downloaded from the net and sitting nicely in /tmp. On reboot, /tmp gets cleared. Session starts and up pop 20+ evince windows most telling me they were "Unable to open document". To which my obvious question is: what document? This is highly frustrating. I think evince should tell me what the document is, so that I can find it again. Sometimes I've even saved a copy, but it doesn't matter if I can't remember what it was. Below is a one-line patch adding the URI to the message. It is relative to 3.4.0 but the bug's been there for over five years, and the details of the patch are not really important. --- evince-3.4.0/shell/ev-window.c 2012-02-22 06:12:16.000000000 +1100 +++ evince-3.4.0local/shell/ev-window.c 2012-08-29 15:33:43.000000000 +1000 @@ -1728,7 +1728,7 @@ ev_password_view_ask_password (EV_PASSWORD_VIEW (ev_window->priv->password_view)); } else { ev_window_error_message (ev_window, job->error, - "%s", _("Unable to open document")); + "%s: %s", _("Unable to open document"), job_load->uri); ev_window_clear_load_job (ev_window); } }
Please attach patches as attachments so they can be searched for. Also, the current patch would probably not work for Right to Left languages.
Created attachment 222717 [details] [review] Patch against evince 3.4.0 to add URI to error message
Points taken. How about the patch attached?
I think if save-a-copy was invoked on a doc in /tmp, we should internally update the EvWindow to point to the copy instead of the original in /tmp.
(In reply to comment #4) > I think if save-a-copy was invoked on a doc in /tmp, we should internally > update the EvWindow to point to the copy instead of the original in /tmp. Still the patch makes sense to me, but also in a different scenario: if I try to open a recent file which has been deleted, moved or renamed. Specially for the later in cases like: "Oh, I remember I renamed it before going to vacation. Where it was?" The file name (if it has the whole path) would give me a clue.
Even though this bug report was reported before, I think the new one makes a better case and also the patch considers the two functions that open a file and can fail. *** This bug has been marked as a duplicate of bug 697900 ***