Bug 197464
| Summary: | gtkunixprintdialog: Trying to print on a printer class kills OO.o | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicolas Mailhot <nicolas.mailhot> | ||||||
| Component: | gtk2 | Assignee: | Matthias Clasen <mclasen> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | caolanm, johnp | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-07-25 04:11:15 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 150223 | ||||||||
| Attachments: |
|
||||||||
|
Description
Nicolas Mailhot
2006-07-02 10:13:53 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->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 ? 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 CCing John, who wrote all of the cups backend code Nicolas, just to clarify: It works if you select a regular printer (as opposed to a class) ? If it didn't I'd have opened another vengeful bug ;) 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. 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.
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.
Both patches look fine, please commit them upstream. Should be fixed in gtk 2.10.1 |