[Gnome-print] Pre 0.21 issues

[Lauris Kaplinski <lauris helixcode com>]

Hi all gnome printers!

We badly need to settle gnome-print api ASAP. The font part, I have beed
dealing with, should be future compatible now. But what is not, is
printer/driver/preferences setting, job routing and querying.

I propose following (mostly the same, I already wrote):

We can live by now with existing GnomePrintDialog widget. For routing
setup, lets use 4 objects:

printer (const gchar *) - a name for printer
driver (const gchar *) - interpreted by printmanager, usually module name
  or similar
settings - big and complex object, implementing attribute/value pairs for
  printer setup. Until we decide its proper structure we can use opaque
  datatype for API.
ticket - (const gchar *) - datatype manipulated by printmanager

We can live at moment with existing GnomePrintDialog and methods:

printer = gnome_print_dialog_get_printer (w);
driver = gnome_print_dialog_get_driver (w);
settings = gnome_print_dialog_get_settings (w);
ticket = gnome_print_manager_get_ticket (printer, driver);
pc = gnome_print_manager_get_context (ticket, settings);

/* Do printing */

gnome_print_context_close (pc);
gnome_print_manager_release_ticket (ticket);

/* Default can be used */

printer = gnome_print_manager_default_printer ();
driver = gnome_print_manager_default_driver (printer);
pc = gnome_print_manager_get_context (ticket, NULL);

/* if you are interested */

status = gnome_print_manager_get_ticket_status (ticket);
str = gnome_print_manager_get_ticket_status_string (ticket);
And much more in future, such as job killing, rerouting...

This should be sufficent and extensible by now, so developers can start
doing things without fear of API breakage.
One problem is, that settings actually encode 3 different sets of options:
- for printer
- for driver
- frontend (such as multipage, mirrored, etc.)
But we can encode thse nicely into single object and make parts acessible
later, if needed.

Comments? Flames?

Lauris