system-config-printer

[John (J5) Palmieri]

Overview on how desktop printer configuration currently works:

1. Printer is plugged in
2. HAL is notified and calls the printer-update.hal shell script 
   in /etc/hal/capability.d/
3. hal_lpadmin from the hal_cups_utils package is called with the 
   printer's udi (what HAL uses to identify devices).
4. hal_lpadmin checks to see if the device is a printer and if so 
   gets the make and model of the device from HAL
5. A command is constructed to execute printconf's match-driver command
6. If a match is found we 
	- construct printconf's add-local command to add the printer
	- execute printconf-backend --force-rebuild to output the cups 
	  configuration files
	- send a HUP signal to cups to reload its data
 
7. If a match is not found we
	- Ask the console user's session through eggcups if they have a 
	  driver match for the make and model in gconf
		- if no we then prompt the user to select the closest 
		  make and model that matches their printer and is in 
		  our foomatic database
			- The user selects a make an model which is then
			  entered into gconf and a message is sent to 
                          cups-config-daemon which executes step 6
			  with the selected make and model
		- if yes we get the make and model returned by gconf
		  and go back to step 6

* On session startup eggcups will loop through the list of printers in
gconf and configure them if they exist in HAL

What printconf does (I have limited knowledge of how printconf works so
can you correct me here Tim?):

* printconf's match-driver command will return the name of the driver 
  given a make and model of a printer
	- if a driver is found go to step 6 above
* printconf's add-local command sets up a local print queue in the 
  sysconfig database using the make and model of the printer.
* printconf-backend --force-rebuild outputs the queues it finds in
  the sysconf database into cups config files.
	- the make and model are looked up in foomatic
	- a PPD file is written out based on the config info 
	  in foomatic
	- printers.conf is updated with the new queue info
	- the queue is created in /var/spool/cups
* The HUP signal to cups tells it to reload its config files and pick 
  up the new printers

That is the basics.  A lot of the desktop configuration can be
simplified by putting functionality into the backend.  I will post a
list of features and designs I would like to see go into a rewritten
system-config-printer soon.
 
On Tue, 2005-02-01 at 12:11 +0000, Tim Waugh wrote:
> The tool we provide for configuring printers needs to change.
> 
> The one we have works as designed, but unfortunately the design was
> that:
> 
> * print queue configuration is stored in an XML file
> 
> * a front-end interface allows the user to manipulate the XML file
> 
> * a back-end program, which runs at spooler start-up time, writes out
>   spooler-specific configuration based on the XML file
> 
> There are several bad consequences of this:
> 
> * the XML file format was and is inflexible
> 
> * the configuration options are limited to those common to both
>   spoolers we were shipping at the time the XML format was decided
> 
> * it is VERY SLOW: you can't *modify* configuration, only write out
>   entirely new configurations (i.e. trigger the back-end)
> 
> * again, due to the XML format chosen, we are tied to the foomatic
>   database in such as way that we absolutely require foomatic to know
>   about the printer before we can configure it.
> 
>   Even if you have the manufacturer's PPD file, there is very little
>   you can do to get your printer working.
> 
> * changes made using the CUPS configuration interface
>   (http://localhost:631/), or any other method external to
>   system-config-printer, are not reflected in the XML file and so
>   cannot be modified.
> 
> * changes made using system-config-printer cannot be modified using
>   other tools, since changes will be overwritten.
> 
> and so on.
> 
> Does anyone have ideas for how system-config-printer should be
> re-written?
> 
> Thanks,
> Tim.
> */
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com