Bug 197464 - gtkunixprintdialog: Trying to print on a printer class kills OO.o
gtkunixprintdialog: Trying to print on a printer class kills OO.o
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gtk2 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
:
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2006-07-02 06:13 EDT by Nicolas Mailhot
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-25 00:11:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Nicolas Mailhot 2006-07-02 06:13:53 EDT
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

gtk2-2.9.4-1
cups-1.2.1-16
openoffice.org-core-2.0.3-7.1

If it changes something, this is a x86_64 system
Comment 1 Caolan McNamara 2006-07-02 15:03:38 EDT
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->openoffice.org->general->use
openoffice.org dialogs" then you get the "classic" openoffice.org 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 15:22:52 EDT
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 15:27:52 EDT
CCing John, who wrote all of the cups backend code
Comment 4 Matthias Clasen 2006-07-02 15:29:06 EDT
Nicolas, just to clarify: It works if you select a regular printer (as opposed
to a class) ?
Comment 5 Nicolas Mailhot 2006-07-02 15:47:04 EDT
If it didn't I'd have opened another vengeful bug ;)
Comment 6 John (J5) Palmieri 2006-07-05 16:13:05 EDT
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 18:22:30 EDT
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 18:55:54 EDT
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 12:59:48 EDT
Both patches look fine, please commit them upstream.
Comment 10 Matthias Clasen 2006-07-25 00:11:15 EDT
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.