GNOME Bugzilla – Bug 480964
evince aborts printing when window is closed during creation of print job
Last modified: 2009-02-18 14:23:25 UTC
steps to reproduce: 1. make sure your cpu load is at 100% 2. open a large document (> 100 pages) in evince 3. print document in evince 4. close evince immediately result: document is not printed expected result: document is printed
I have created a patch for this bug. Evince was preparing the document for printing in a background job. This job was canceled when Evince was closed. The patch solves this by 1) not canceling the print job when the document window is closed 2) hiding instead of deleting the document window, when there are still print jobs running. (this is needed, because some printing code depends on the window) Furthermore I found that printing setting may be associated with the wrong print job if the user prints the document multiple times with different settings within a short period of time (i.e. when the first print job is not finished yet). This is also fixed in this patch. Additionally I changed the print job title from "evince_print" to the document name. This is my first patch to an open source project, so tell me about my mistakes.
Created attachment 96288 [details] [review] my patch
Thank you very much for reporting and for the patch. This is indeed a known problem. It also happens when saving a copy, for instance. Your patch looks good in general, however I think it's not enough. We can't know if the user closes evince expecting any pending operation to be aborted or finished. It's also very strange when evince is launched from a terminal and, once it's closed, the window is hidden but the process is still running. The main problem is that we are failing to provide good feedback in several situations and this is one of them. In this case I think we should provide feedback about the progress of the job and we should allow the user to manually cancel the job. This way, when the user closes evince he/she knows that there is still a job in progress. We could even show a dialog warning that a job is running with the options: Cancel, Close aborting the print and Close without aborting the print. There are other situations where we are failing to provide good feedback: * Opening remote files. For big files it could take several minutes and we are just showing the main window with a static "Loading..." label. It really looks like it's hanged and it's impossible to know the remaining time. I think we already have a bug about this. * Features exposed through the sidepane are really hard to discover. For example, the only way to know if a document has attachments is explicitly opening the sidepane drop down menu. We are probably going to add more features to the sidepane in the future such as annotations, comments, digital signatures and so on. Adding Bryan to CC since his opinion would be very appreciated.
(In reply to comment #3) > Thank you very much for reporting and for the patch. This is indeed a known > problem. It also happens when saving a copy, for instance. > > Your patch looks good in general, however I think it's not enough. We can't > know if the user closes evince expecting any pending operation to be aborted or > finished. I don't think the normal/non-technical user wants to know that background jobs are running. After clicking on "Print" the user expects evince to handle all things necessary to print out his document. If he wants to cancel printing he uses the system tray icon to delete the print job after it has been submitted to the printing system. > It's also very strange when evince is launched from a terminal and, > once it's closed, the window is hidden but the process is still running. Yes, that's a good point. We could print out a message on the terminal, something like: "Background print jobs are being processed. Press CTRL+C to abort." > The > main problem is that we are failing to provide good feedback in several > situations and this is one of them. In this case I think we should provide > feedback about the progress of the job and we should allow the user to manually > cancel the job. This way, when the user closes evince he/she knows that there > is still a job in progress. We could even show a dialog warning that a job is > running with the options: Cancel, Close aborting the print and Close without > aborting the print. I think this is too complicated and would be annoying for most users. I often have a folder with, say, 5 large PDFs in it. I open one of them, look briefly at it, click on print, immediately close this document and then open the next. A warning dialog every time I close a document while evince is still printing would be very bad for my workflow. I like that evince keeps things simple and I do not have to bother with background jobs. > > There are other situations where we are failing to provide good feedback: > > * Opening remote files. For big files it could take several minutes and we are > just showing the main window with a static "Loading..." label. It really looks > like it's hanged and it's impossible to know the remaining time. I think we > already have a bug about this. Yes, a progress bar and a cancel button in the status bar would be nice. > * Features exposed through the sidepane are really hard to discover. For > example, the only way to know if a document has attachments is explicitly > opening the sidepane drop down menu. We are probably going to add more features > to the sidepane in the future such as annotations, comments, digital signatures > and so on. We could show little icons that indicate special features in the document. (i.e. a paper clip for attachment, a padlock for digital signatures, a book for bookmarks). Clicking on that icons would open the sidebar with the right selection. We could use the free space in the right corner of the menu bar for these icons if it is possible with GTK+. > > Adding Bryan to CC since his opinion would be very appreciated. >
(In reply to comment #4) > > I don't think the normal/non-technical user wants to know that background jobs > are running. Agree, I'm not talking about background jobs as a low level tasks, I mean, I think the user is interested in the progress of its print task and he should be able to cancel it. > After clicking on "Print" the user expects evince to handle all > things necessary to print out his document. If he wants to cancel printing he > uses the system tray icon to delete the print job after it has been submitted > to the printing system. hmm, I think such a systray icon depends on every distro, I don't have it, for instance. > I think this is too complicated and would be annoying for most users. I often > have a folder with, say, 5 large PDFs in it. I open one of them, look briefly > at it, click on print, immediately close this document and then open the next. > A warning dialog every time I close a document while evince is still printing > would be very bad for my workflow. I like that evince keeps things simple and I > do not have to bother with background jobs. Agree, if we have a way to cancel the print job we could probably avoid such annoying popup.
(In reply to comment #3) > * Opening remote files. For big files it could take several minutes and we are > just showing the main window with a static "Loading..." label. It really looks > like it's hanged and it's impossible to know the remaining time. I think we > already have a bug about this. I've just realized that gedit already implements a solution for this. It's a message area with a progress bar and a cancel button. I think it's a very good solution. We could copy and paste such code from gedit, or even better, it could be moved to libegg, for instance, so that other applications like eog could take advantage of it too.
Evince still aborts printing when the window is closed. Very annoying when printing several large documents directly from within the browser ("Open with Evince" instead of "Save to file.."). It's open, print, close and if the job hasn't finished, it's really annoying to have to browse back to the original page and re-download, re-print all documents.
My sister ran into this problem. The problematic document took approx. five minutes till it got send to the printer. I already suspected a problem with the cups installation, but in the end it just took awfully long. I just talked to my sister and she said: "If it takes _that_ long, it should at least tell me!". And the CPU-Fan alone is not enough of an indicator.
Fixed in svn trunk. Thank you all for your help.
*** Bug 572274 has been marked as a duplicate of this bug. ***