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?
Comments
13 responses to ““New printer” notification mock-ups”
The generic drive doesn’t look important enough for users to think they need to do anything. They are thinking, “Great! I have the generic driver, and everything is going to work! Wow, Linux is great!”
Yes, I see what you mean — there is no reason for them to think that a generic driver is a poor choice.
Perhaps it should look the same as the “Missing printer driver” bubble when a generic driver is used.
…and maybe the “Searching for driver…” bubble isn’t needed; it can just be that the icon changes (in the screenshot it’s got a magnifying glass on it, which might not be the best thing but shows what I mean).
I like the idea, but also be careful not to end up throwing too many notifications at the user; it’s something I don’t mind occasionally but it’s being used more (i.e. SELinux Alerts in F7). Perhaps it could just notify if there is a problem?
JonRob: the “searching for driver…” one is overkill, I agree. Getting rid of that just leaves one bubble telling us the name of a queue created for a printer, the first time it is plugged in.
Last time I bought a printer, Fedora (5 I think) didn’t know the model. At that point I had 2 wish list items for this area:
First, I got a CD with the printer that had drivers on it. So one nice option would be to ask “did you get a CD?” and then open the drive, let me pop it in, and look for the needed files.
Another idea would be to just download the needed PPD from some web site, say something Fedora related. Ideally this could be updated with some frequency.
I’m not a print expert so I have no idea how plausible these things are.
Tom: I remember you suggesting both of these things. That’s part of why I want to make this work better.
The “Find Driver” button is the chance to provide the driver. Currently the dialog that “Find Driver” will hook into has two radio buttons:
* Select Printer from database
* Provide PPD File
and the “Provide PPD File” one has a Browse button which brings up the GTK+ file selection dialog.. and from there you can browse the CD-ROM. Is there a way to make that better?
As for downloading the PPD from a web site, happily we aren’t very far off that now. Till Kamppeter has made a web API on openprinting.org:
http://www.linux-foundation.org/en/OpenPrinting/Database/Query
This allows us to look up drivers by IEEE 1284 Device ID strings, and our D-Bus NewPrinter call will include those strings for precisely that reason. For the case where there is no reasonable driver to use, system-config-printer would be able to use the OpenPrinting API. It just needs doing.
[…] Printer dialog mockups and automatically finding a printer driver via an API over the web « Full Circle, we’ve now got Windows Registry | […]
Tim — this sounds excellent to me.
FWIW, this is now giving real notifications in the development packages. You need:
hal-cups-utils-0.6.10-1.fc8
system-config-printer-0.7.66-1.fc8
It won’t be quite working as designed until I can stop it parsing the foomatic XML, so that’s the next task.
[…] like the New Printer notification bubbles from Fedora 8 are going down well in Ubuntu […]
[…] to this post for more information. This tool also has been adopted by the latest version of Ubuntu 7.10. We […]
[…] first steps for using the OpenPrinting.org API which I’ve mentioned before have now been checked into the trunk of system-config-printer. Today’s release, 0.7.79, […]