GNOME Bugzilla – Bug 684533
GTK print dialog does not allow printing and does not show options of a remote DNS-SD/Bonjour printer
Last modified: 2018-05-02 15:30:54 UTC
Created attachment 224912 [details] [review] print-dialog-show-options-of-remote-dnssd-printers.patch Original report to Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1053891 From CUPS 1.6.x on CUPS does not broadcast shared printers any more using its own method, leading to the fact that clients do not discover and make available printers on remote CUPS servers automatically any more. Now one has to explicitly add the printer on the client. To allow at least discovery of the server's printers, the server broadcasts the printer information via DNS-SD/Bonjour (using the Avahi daemon). Creating a queue on the client based on these broadcasts is easy, system-config-printer shows the server's host name under the discovered network printers and choosing this allows to use the shared CUPS printer. On the client we then have a raw queue (no local PPD/driver, we use the server's one) with a device URI like this: dnssd://Color%20Laser%20Printer%20%40%20server._ipp._tcp.local/cups One can print on this printer via the "lpr" command and one can display the options (defined in the PPD file on the server) with "lpoptions -l". If one opens the GTK print dialog (for example in evince), the printer gets listed but it says "Getting printer information ..." infinitely and the "Print" button stays grayed out, making printing through the GTK dialog impossible. This is a major problem as it prevents printing on printers shared between computers running CUPS 1.6.x. The fix is simple and a patch is attached. To reproduce: Take two Quantal machines, both need to run CUPS and Avahi, the client needs to run a desktop and have GTK applicatiuons installed. On the server create a print queue with system-config-printer or by simply plugging in a USB printer, do not create a raw (driverless) print queue. Share the printer ("cupsctl --share-printers" or "Server"/"Settings" in system-config-printer). On the client create a queue pointing to this printer, in system-config-printer click the "Add" button and in the printer setup wizard wait for the spinning icon to disappear, under the network printers choose the host name of the server and complete the wizard, you will not get asked for make, model, or driver. You will be able to print a test page and to browse the printer's options with system-config-printer. You also will be able to print from the command line or from KDE applications. If you try to print from GTK applications the queue displays in the dialog but is stuck with grayed "Print" button and "Getting printer information ...".
Review of attachment 224912 [details] [review]: Needs a commit message containing some of the information from this bug report, but looks good otherwise.
Marek, can you have a look into my patch and, perhaps together with your work on bug 688956, do an improvement in terms of asynchronous/multi-threading behavior? If the server to which a the print queue is pointing goes down, the print dialog will hang some seconds, which is annoying. Also queues with URIs like ipps://Budapest%20-%20Fast%20Color%20Inkjet%20Printer%20%40%20till-hp._ipps._tcp.local/cups ipp://Budapest%20-%20Fast%20Color%20Inkjet%20Printer%20%40%20till-hp._ipps._tcp.local/cups (ipp or ipps scheme and rest like dnssd URI) are not yet supported.
Review of attachment 224912 [details] [review]: The patch uses function _httpResolveURI() which is private CUPS function. You can not use such functions. Even if it would be public, it is a blocking function which uses polling mechanism (maybe this is the problem you are talking about in comment #2). The patch also misses breaks after some function names.
The patch was not intended as a final fix, it was more to show what functionality is missing and what piece of existing code is delivering this functionality. I am not expert above with the GTK printing dialog and its asynchronous communication with system and network resources to do it correctly. Marek, therefore I am asking you (and any other experienced GTK developer) whether you could solve the problem which this bug report is about in the correct way, perhaps together with the work on bug 688956.
At least in CUPS 1.6 there is a public API function cups_dnssd_resolve() which seems to do the same as the private _httpResolveURI().
(In reply to comment #5) > At least in CUPS 1.6 there is a public API function cups_dnssd_resolve() which > seems to do the same as the private _httpResolveURI(). Hi, cups_dnssd_resolve() is not public. I can not edit printer options (those which are in the PPD on the server which broadcast it) in system-config-printer if it is installed as written in the reproduce step. It is interesting that cupsGetPPD() doesn't get PPD of such printer for me so we should not probably get it ourselves. Fixing this would overlap with the fix of #688956. Fixing it will show the original printer with correct PPD. I can not reproduce the "Getting printer information ..." problem, which version of gtk+ do you use? Maybe this is something which should be fixed in system-config-printer by assigning a PPD to the new printer. Regards Marek
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Please continue the work on this one. Thanks.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/407.