Got a plan for fixing the printer driver prompt. This is the prompt you get when a driver can’t be found for the printer you just plugged in. The issue is that you can’t say “use this PPD file I’ve got” but instead have to choose from the ones that already didn’t match.
Here is how it worked in Fedora 6: HAL discovers a printer and calls the “add” HAL method on it (which is implemented in hal_lpadmin). This looks for a match, and when it fails it resorts to asking the user for help. It does this with D-Bus: it calls a D-Bus method, PromptPrintDriver (from the com.redhat.PrintDriverSelection interface), which is implemented by eggcups.
All eggcups does with that is display the list of makes and models for you to choose one of them. Once the dialog is displayed, the method returns (and hal_lpadmin exits). If you choose one of the printer models, eggcups calls the “Configure” HAL method on the device, which runs hal_lpadmin again. This loads the foomatic database again (yes, that’s the third time now) to get the PPD, and sets it for the queue.
You didn’t even get to say anything about the PPD that the printer manufacturer provided you with.
In Fedora 7 the situation is actually slightly worse because of the eggcups re-write: now the dialog is not implemented at all. In my defense, I don’t think it can have been much use to anyone in the form described above.
So for Fedora 8 I’d like to fix the short-coming of not being able to provide your own PPD. Here is how it will work:
HAL discovers a printer and calls the “add” HAL method, as before. The hal_lpadmin implementation will try to find a driver match, as before, but this is a lengthy process so the first thing it will do is let the user know that something’s going on. It will do this by looking for a /com/redhat/NewPrinterNotification D-Bus object, and if it finds one it will call the GetReady D-Bus method.
This NewPrinterNotification object will be implemented in the system-config-printer-applet, the replacement for eggcups, and it will do something like this:
So the user has plugged in the printer, and they are now waiting patiently for hal_lpadmin to find a driver. Hopefully it will find an exact driver match. If it doesn’t there is always a fall-back it can use: a close model match, a generic driver, or (as a very last resort!) the text-only driver. In any case, it will add a queue for the printer and call the NewPrinter D-Bus method.
This will put a notification on the screen telling the user what the name of the queue is, with a button to give them an opportunity to find a better driver or configure the chosen driver. If the driver was a perfect match, it should look like this:
There are several reasons why hal_lpadmin might not have found an exact driver match:
- The exact model number wasn’t found, but a close match was
- A close match wasn’t found, but a generic driver for one of the command sets the printer knows was found
- Not even a generic driver could be found, so the driver of last resort (text-only) was used
Here’s the “close match” mock-up, although it should probably not include the “Foomatic/…” stuff:
Here’s the “generic driver” mock-up (note that the button says “Find driver” rather than “Configure”, hopefully conveying the fact that the user might want to try to find a better driver):
And here’s what “missing driver” would look like:
The “Configure” and “Find driver” buttons all do the same thing: launch system-config-printer, telling it to start on the configuration page for that printer. At that point, the user can provide their own PPD if they like.
None of this is implemented, but none of it is particularly hard to do. The important thing is: does it look right?