After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 576601 - Double clicking prints to the wrong printer
Double clicking prints to the wrong printer
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Printing
2.14.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-03-24 18:32 UTC by Jonathan Blandford
Modified: 2009-08-06 07:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
a patch checking request_details_tag and acceptance of jobs (7.65 KB, patch)
2009-07-22 15:40 UTC, Marek Kašík
none Details | Review
modified patch (9.57 KB, patch)
2009-07-27 14:32 UTC, Marek Kašík
none Details | Review
show busy indication (9.83 KB, patch)
2009-08-05 12:21 UTC, Marek Kašík
committed Details | Review

Description Jonathan Blandford 2009-03-24 18:32:50 UTC
When I brought up the print dialog, a given printer in the list was selected.  If I double click on another printer fast enough, it will print on the initially selected printer and not the new one.
Comment 1 Marek Kašík 2009-07-22 15:40:39 UTC
Created attachment 139001 [details] [review]
a patch checking request_details_tag and acceptance of jobs

Hi,

the problem is that GtkPrintUnixDialog processes "response" signal even if there is a request for details of a printer or the printer is rejecting jobs.

Regards

Marek
Comment 2 Matthias Clasen 2009-07-24 15:15:41 UTC
Hmm, but this is basically ignoring the double-click in that case, no ?

I think the expected behaviour would be to print to the printer that was double-clicked, anyway. If necessary, wait for the printer details to arrive before doing so...
Comment 3 Marek Kašík 2009-07-27 14:32:21 UTC
Created attachment 139285 [details] [review]
modified patch

This version waits for details. It makes the dialog insensitive during getting details.
It also changes behaviour of "Print" button's sensitivity. You can press it even if details are not acquired yet.

Marek
Comment 4 Matthias Clasen 2009-07-29 22:15:17 UTC
Hmm, I think I need to try the patch to see how this feels, but from the description, I think that is still suboptimal. 

If this wait for details takes too long, the user may want to cancel (this action, not the dialog as a whole) and try another printer. It would be cool to

a) show some 'busy' indication. A simple thing would be to set a wait cursor on the dialog. Maybe it would be nicer to show a little spinner and 'Getting printer information...' in the action area, on the left side. But that will have to wait until we have a spinner in GTK+

b) make Esc cancel the 'get details' operation without cancelling the dialog. Slightly tricky, since you still want Esc to cancel the dialog when there is no long-running operation.

c) selecting another printer should also cancel the 'get details' operation
Comment 5 Marek Kašík 2009-08-04 12:13:54 UTC
And what about not to allow user to press the "Print" button or double-click the printer, show the busy indication text in the status field of the printer and set the wait cursor?
This would allow user to select another printer without an extra action. And when a spinner will be available we can add it there.
Using Esc for cancelling of "get details" operation would often lead to cancelling dialog instead of cancelling the operation (for example when the operation takes 5 seconds and user presses it late).

Marek
Comment 6 Matthias Clasen 2009-08-04 15:46:30 UTC
> And what about not to allow user to press the "Print" button or double-click
> the printer, show the busy indication text in the status field of the printer
> and set the wait cursor?
> This would allow user to select another printer without an extra action. And
> when a spinner will be available we can add it there.

This sounds better to me.

> Using Esc for cancelling of "get details" operation would often lead to
> cancelling dialog instead of cancelling the operation (for example when the
> operation takes 5 seconds and user presses it late).

You are probably right here. We just need to make sure that you can simply cancel the longrunning get-details operation by selecting another printer or by closing the dialog. 
Comment 7 Marek Kašík 2009-08-05 12:21:34 UTC
Created attachment 139936 [details] [review]
show busy indication

Hi,

this patch shows a busy indication (cursor + state message) and doesn't allow user to print when getting details. It is also possible to change printer in the middle of a details request or cancel the whole dialog.

Regards

Marek
Comment 8 Matthias Clasen 2009-08-05 16:03:59 UTC
+                          PRINTER_LIST_COL_STATE, N_("Getting printer information..."),

I think you want to use _() here, not N_() ? I don't see where the actual translation would happen, otherwise...

Other than that, it looks fine to me. 

Please commit with that fix. And please send a quick note about the new string to gnome-i18n@gnome.org. Thanks.
Comment 9 Marek Kašík 2009-08-06 07:48:33 UTC
> I think you want to use _() here, not N_() ? I don't see where the actual
> translation would happen, otherwise...

You are right, I wanted to use _() instead of N_() actually.

Committed:
  Check for details request before print

  Checks for details request before sending a job to a printer.
  Shows busy state indication (cursor + status field).
  This avoids printing to wrong printer (bug #576601).

Regards

Marek