Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 197464 - gtkunixprintdialog: Trying to print on a printer class kills OO.o
Summary: gtkunixprintdialog: Trying to print on a printer class kills OO.o
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk2
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact:
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
Reported: 2006-07-02 10:13 UTC by Nicolas Mailhot
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-07-25 04:11:15 UTC

Attachments (Terms of Use)
Gets the correct ppd name if we find a class (deleted)
2006-07-05 22:22 UTC, John (J5) Palmieri
no flags Details | Diff
Fix the parameters we send when emitting the details-acquired signal (deleted)
2006-07-05 22:55 UTC, John (J5) Palmieri
no flags Details | Diff

Description Nicolas Mailhot 2006-07-02 10:13:53 UTC
My local printer (usb2 Brother HL 5050) is accessed through several printing
paths : default PS driver, PS with vendor PPD, PCL
I've defined a general local printer class which groups the 3 aforementionned paths

Just selecting this class in OO.o print dialog causes OO.o to crash


If it changes something, this is a x86_64 system

Comment 1 Caolan McNamara 2006-07-02 19:03:38 UTC
If simply just selecting it causes some sort of crash then it's likely a problem
with the gtk print stuff.

caolanm->mclasen: does anything else actually use the gtk print dialog yet to
verify that it's a generic issue ?

caolanm->nicolas: if you tick "tools->options->>general->use dialogs" then you get the "classic" print and file
dialogs, if you do this and visit that printer in the classic dialog does it
function correctly ?

Comment 2 Nicolas Mailhot 2006-07-02 19:22:52 UTC
The native OO.o dialogs work
But they don't try to display a lot of the info the gtk2 ones do, and I since
printer classes do not expose some of this info like normal printers, that would
explain the crash

Comment 3 Matthias Clasen 2006-07-02 19:27:52 UTC
CCing John, who wrote all of the cups backend code

Comment 4 Matthias Clasen 2006-07-02 19:29:06 UTC
Nicolas, just to clarify: It works if you select a regular printer (as opposed
to a class) ?

Comment 5 Nicolas Mailhot 2006-07-02 19:47:04 UTC
If it didn't I'd have opened another vengeful bug ;)

Comment 6 John (J5) Palmieri 2006-07-05 20:13:05 UTC
I tracked this down to two bugs.  

First and the easiest to fix is that when requesting a ppd from a class we must
request a ppd from the first printer in the class.  This was not seen in
previous tests because the printer name and the class name were the same.

The second issue is that when the GET fails to get the PPD is should try again
only a finite number of times.  For some reason it keeps trying.  That will take
a bit more digging to fix.

Comment 7 John (J5) Palmieri 2006-07-05 22:22:30 UTC
Created attachment 131968 [details]
Gets the correct ppd name if we find a class

This should fix the first issue.  It is not quite a complete fix.  In CUPS 1.2
you can have classes of classes.  Cups handles this by recursively going down
the tree, getting a new connection, and checking the first printer of the class
until it finds an actuall printer.  This is easy to do using blocking calls but
much harder in our async world view.  It is also costly since one needs to get
a new connection for each branch of the tree it decends down into.  Also Cups
seems to allow circular refrences so you can have one class that contains a
class that contains the first class.  Don't ask me why they didn't put the
logic in the server for getting ppd's from classes.

Comment 8 John (J5) Palmieri 2006-07-05 22:55:54 UTC
Created attachment 131970 [details]
Fix the parameters we send when emitting the details-acquired signal

For some reason we were sending in the printer as a parameter which got
marshled as the success boolean.  This cause the signal to always say it had
succeeded and call the selected_printer_changed method which would check for a
PPD, see it was not found and call request_ppd which would start the cycle all
over again.

This patch fixes the second problem.

Comment 9 Matthias Clasen 2006-07-06 16:59:48 UTC
Both patches look fine, please commit them upstream.

Comment 10 Matthias Clasen 2006-07-25 04:11:15 UTC
Should be fixed in gtk 2.10.1

Note You need to log in before you can comment on or make changes to this bug.