Description of problem: The print dialog shows the current state of each queue, which is very useful. However, when this is performed for a busy queue, the snapshot at the point where a new job has just begun can look alarming. The reason is that the job backend has started to connect to the device, so it sets the 'connecting-to-device' state reason for the queue. A moment later it will hopefully remove that state reason. Unfortunately the GTK+ print dialog interprets 'connecting-to-device' as a reason to display a printer-error icon and a "may not be connected" message. Really it should not display this message unless that state reason has been there for 'a while'. For example, system-config-printer-applet waits for 60 seconds and only shows a warning if the connecting-to-device state reason has been continuously present. The GTK+ print dialog doesn't have the luxury of waiting that long, but perhaps it should wait until it has seen it in two successive polls or something? Version-Release number of selected component (if applicable): gtk2-2.14.7-8.fc10 How reproducible: 100% Steps to Reproduce: 1.Open print dialog 2.Queue several short jobs to an active queue 3.Watch the dialog Actual results: "may not be connected" message can flash on screen for a few seconds.
Yes, that makes sense to me. I'll ask Marek to take a look at this.
Hi, the "Printer '%s' may not be connected." message is taken from system-config-printer. The error icon is showed because there is no suffix (warning or report) and according to IPP's RFC (4.4.12) it should be treated as an error. The problem of successive polls is that 2 are not enough and I can imagine that 5 will not be enough in some cases (in Fedora 10, 11). One solution is to set the number of successive polls with "connecting-to-device" to a very high number (for example 10 for Fedora 10, 11 and 150 for Fedora 12). Second solution could be an ignoring of this printer state reason. Third solution can be showing of a text like "Connecting to printer '%s'." without any emblem on printer's icon. The first one is a heuristic which can work, the second is not very nice and the third seems acceptable for me (user is informed and happy :) ). Which solution do you prefer (I prefer the third one)? gtk2 do its own connection test for remote printers since Fedora 12. Do you think that it is enough to not indicate the "connecting-to-device" reason when the test is successful? Regards Marek
Yes, third suggestion sounds best.(In reply to comment #2) > gtk2 do its own connection test for remote printers since Fedora 12. Do you > think that it is enough to not indicate the "connecting-to-device" reason when > the test is successful? If you mean that connecting-to-device shouldn't be regarded as an error state reason, yes I think that's best.
Hi, when diving more into the problem I see that "printer-state-message" already sets a message describing actual situation for the "connecting-to-device" reason. It shows these messages: "Printer is now online.", "Copying print data...", "Waiting for job to complete..." and "Connecting to printer...". So the second solution seems the best for me now. Marek Btw, I found out that the connection test is performed only when getting PPD for actual printer, so we doesn't have this information for all printers.
gtk2-2.14.7-9.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gtk2-2.14.7-9.fc10
gtk2-2.18.3-21.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gtk2-2.18.3-21.fc12
gtk2-2.18.3-21.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gtk2'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11415
gtk2-2.18.3-21.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
gtk2-2.14.7-9.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.