There are a few cases where the job list window (the one thats popped up from the statusicon) doesn't get the status quite right. When the list is empty, and I print a document 'on hold', the job shows up in the list as 'processing'. It seems to be on hold anyway, since it just stays there (of course, I cannot release it, since only cancel is sensitive for jobs which are thought to be 'processing'). When the list is not empty, a job printed as 'on hold' shows up as 'pending' in the list. Shouldn't it be shown as 'Held' ? If I cancel the job that sits before it in the queue, it changes to 'processing', but seems to not actually be processed (since it is on hold, after all...) Finally, a small ui complaint: When the list has more jobs than it can show (ie scrollbars are visible), and the list is scrolled to the top, then adding a new job should probably make the new job visible. The way things currently are, the new job is added above the top row, and only the small jump in the scrollbar indicates that something has changed.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I just looked at this. It says 'processing' because the submitted job is not held, because it was not submitted as held. I tried both from the command line and from gedit, and from the command line I get: 1. (after 'echo . | lp -H hold'): a single job listed as 'Held' 2. (after doing that again): two jobs, both listed as 'Held' From gedit, selecting 'On hold' in the Job screen, the resulting job is actually processing, not held. This happens for two of the three printers -- for some reason it does work (the job is submitted held) for one of them. -> GTK+ bug. As for the UI complaint, I'm not sure what a good rule is. If jobs are being submitted constantly it will be *really annoying* if it scrolls back to the top each time, and will make examining history impossible. Probably needs a separate bug report.
>it will be *really annoying* if it scrolls back to the top >each time, and will make examining history impossible. thats why I only said to keep it scrolled to the top if it was before. If you scroll down to examine history, new jobs should not cause scrolling.
Think I may have checked in a fix for the scrolling thing upstream, based on get_visible_range(). Seems to work here.
Marek, can you have a look at the held/processing issue ?
I'll look at it. But I'm busy with another bug now. Marek
*** Bug 490647 has been marked as a duplicate of this bug. ***
Hi, it seems that this is not a bug in gtk. I think that problem is in processing of jobs after their submission. I reproduced this only with shared non-local printers. There is no problem with local printers. When I print a job "on hold" (or with specified time) on a non-local printer then I get "processing" status in local print queue but "held" ("held until ...") status in the non-local print queue. If more than one job is sent to a non-local print queue then only the first arrives (with correct status in the non-local queue and "processing" status in local queue) and remaining jobs are waiting in local queue (with "pending" statuses in the local queue) for the "free slot". Regards Marek
Ah, so is this related to the upstream bug that asks us to queue all jobs locally, then ?
I think that this is not related to the upstream bug (#585565). All jobs are already queued locally and jobs show up in the local queue and also in the non-local queue. This was solved in rh bugs #248245 and #449379 (which indicates that the upstream bug is not correct - I'll look at it). Marek
Confirmed. Thanks for investigating. Although this command does appear to work: lp -H 18:00 /etc/fstab in that it shows at 'Held until ...' initially, after five minutes (the multiple-operation timeout) the job starts processing and actually gets printed on the remote queue.
Filed upstream with patch.
cups-1.4-0.rc1.10.fc11 has been pushed to the Fedora 11 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 cups'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6680
cups-1.4-0.rc1.10.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.