Bugzilla – Bug 154596
Gnome asks to configure printer already configured in YaST
Last modified: 2007-02-21 23:18:02 UTC
If a printer is added through YaST, then a user goes into gnome and turns on the printer, GNOME asks to configure it. KDE does not ask to configure the printer if it's already configured in YaST. Both KDE and GNOME should pull printers from the same database. Printers configured in YaST seem to be the best place to get this from.
Created attachment 70895 [details] Screenshot Screenshot of popup in Gnome when a printer is turned on that is already configured in Yast
They are done by the same database, but cups has multiple backends. gnome uses hal://, yast uses cups://
imho, the way to fix this is to make use hal, which is what they should be using anyway. there's no way for gnome to map a hal udi for a printer to a printer configured in the cups database using another backend.
Reassigning to the gnome maintainers.
Larry found some issues that make this more serious.
Discussion in #154299 pertains to this bug.
I just submitted a new g-v-m with a add-unknown-printer script that tries to match hal udi's against usb uri's and if it doesn't find a match, it launches `yast2 printer` so presumably this can be marked FIXED now (altho doing this type of matching is kinda fuzzy so we can't ever expect this to work 100% until yast2 is fixed to use the hal CUPS backend instead of hardcoding the usb backend)
I actually fixed the add-unknown-printer script to launch gnome-cups-add instead (which is the program g-v-m launched before) but had to fix gnome-cups-add to directly query the usb backend for a list of usb detected printers since we can't seem to rely on querying CUPS via the IPP interfaces for local printers (it doesn't seem to update itself that often). I hope that this only remains as a temporary solution (altho my patch to gnome-cups-add can probably be kept eternally - at least as long as querying CUPS isn't up-to-the-second up-to-date). If we could eventually move to a backend like the hal backend[1], then we could start using gnome-cups-add --printer=hal:///org/freedesktop/HAL/... and it could (as it did a short time during BETA) correctly choose the Vendor for the user in the first page of the "Add New Printer" wizard and flip to the second page and attempt to auto-magically select the correct Model of printer as well[2] 1. altho, agreeably the hal backend won't handle the usb printer/scanner dual devices as I hear the usb backend does, but maybe that can be fixed to work? 2. This matching logic uses fuzzy string matching currently (and so is anything but perfect), but if we could perhaps add some sort of HAL property via fdi files(?) like printer.preferred_ppd, then we could do much more reliable auto-selection of the correct PPD for the user. This doesn't mean we wouldn't let the user override the PPD file used for printing, but at least in the common case - the user wouldn't have to do anything except glance over what we auto-selected for him/her and click a "Finish" button. I'm closing this bug now but continue to hope that the above solution can be implemented at a future date as an even better solution than what we will be shipping for NLD10
woops, forgot to close