GNOME Bugzilla – Bug 753041
Printer information not properly initialized if starting a print job within gtk_enumerate_printers
Last modified: 2018-04-15 00:21:34 UTC
Looking at [1], it appears that the printer-added signal, which gtk_enumerate_printers appears to listen for synchronously, is fired before things like the printer state or various capability members are set[2]. This seems to at least result in the printing backend thinking that a printer cannot do multiple copies if we attempt to kick off a print job from within gtk_enumerate_printers. The work around is to defer starting the print job until the next tick of the event loop so that the members can be set. Note that this ordering is inconsistent with a different location[3], where printer-added is fired just after the capability members are set. [1]: https://git.gnome.org/browse/gtk+/tree/modules/printbackends/cups/gtkprintbackendcups.c?id=3.10.8#n3119 [2]: https://git.gnome.org/browse/gtk+/tree/modules/printbackends/cups/gtkprintbackendcups.c?id=3.10.8#n3131 [3]: https://git.gnome.org/browse/gtk+/tree/modules/printbackends/cups/gtkprintbackendcups.c?id=3.10.8#n2485
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.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new