[Gnome-print] Re: GnomePrintSettings

[Lauris Kaplinski <lauris helixcode com>]

Hello!

> <brain storm>
> We create a new Object called "GnomePrintSettings", which is an opaque
> object. The widgets for Paper Orientation, Print Margins & Paper size
> can be created by gnome-print from this Object. When the "Properties"
> button on the  print dialog is poped up, the GnomePrintSettings object
> is updated.  This object also has methods to read/writer printer
> settings to xml.
> 
> When a new document is created it contains a pointer to a
> GnomePrintSettings object, this object is created with :
> 
> GnomePrintSettings * gnome_print_settings_new ()
> 
> Since we want this settings to be stored inside a document, we provide
> XML functions to read/write them. (Ascii functions as well ? Maybe)
> 
> void               gnome_print_settings_xml_write (XmlNodePtr parent);
> GnomePrintSettings gnome_print_settings_xml_read (XmlNodePtr node);
> 
> in _write the parent node ('Say "PrintSettings" is already created) we
> do everything below that node. So the app would do something like :
> 
> node = xmlNewChild (node, gmr, "PrinterSettings", NULL);
> if (!gnome_print_settings_xml_write (node))
>        return NULL;

1. Better to give _write toplevel settings node (not parent) - gives us
cleaner structure for handling options partially by app, partially by gpa.
2. There should be a way to ask writing per key ("paper", "color", etc.)
in case application is not interested in embedding full printer
specification (location etc.).
I.e. the generic rule about gpa stands - you can get/set/interpret all
setting in gpa manually if you know the keys. Some of the keys are
generally known (like paper size etc.), some are meaningful only to
gpa/gnome-print library internals.

> [Opposite for reading].
> 
> When the app needs to pop up a "Paper Settings" or "Print Settings"
> dialog, it uses the GnomePrintSettings for creating the widgets. To
> create PaperOrientation, PaperSize & Paper Margins widgets from this
> object. We would call :
> 
> a) GtkWidget* gnome_print_settings_paper_size_widget_new
>                           (GnomePrintSettings *gps,
>                            GnomePrintPaperSizeWidgetType type); 
> b) GtkWidget* gnome_print_settings_paper_orientation_widget_new
>                           (GnomePrintSettings *gps,
>                            GnomePrintPaperOrientationWidgetType type);
> c) GtkWidget* gnome_print_settings_paper_widget_new
>                           (GnomePrintSettings *gps);
>                                            
> (c) = (a) + (b) + visual representation of paper
> 
> [ Yes, lauris I know you like short function/enums names, this is just
> to get the ideas down, we can use shorter names :-)]
> 
> I think we need to use a type argument because there are different
> layouts for this widgets. One can set a Paper Size that includes a Visual
> representation of the  paper, or the orientation in a GtkOptionMenu or
> GtkRadio buttons etc..

Hmmm...
Why not to use gtktypes here.
I.e. gnome_print_settings_new (GtkType type, gps);
And every _settings widget should simply implement
::build (GPSWidget * w, GnomePrintSettings * gps)
class method for initialization.
This would compact API a lot - we will have on single public
get_type () method per widget class and very common few base methods.
Everything else can be private.

> When the app prints
> ===================
> Since the App no longer handles print orientaion/Paper Size. Before it
> prints it queries gnome-print for the print Bounding Box (margins 
> substracted / margins NOT substracted ). With :
> 
> void     gnome_print_get_print_bbox (GnomePrintContext *pc,
>                                      gboolean substract_margins,
>                                      gdouble *widht,
>                                      gdouble *height);
> 
> (do we need the substract margins ??? )
> 
> The substract_margins is a flag to get the Page size, v.s. the printable
> size. I am not sure we need this, but there needs to be a way for the
> app to get the area in which it can actually draw inside the paper.

Wait...
Why to handle that through PrintContext at all? After all PrintContext
is simply a driver and cannot know anything more than gps already does
about printer/page/... capabilities.
I would instead use:
ArtDRect pgrect, vrect;
gnome_print_settings_get (gps, "page-size", &pgrect, "printable-size",
  &vrect, NULL);
gdouble affine[6];
gnome_print_settings_get (gps, "raster-transform", affine, NULL);
to get the actual affine transform from base page (72dpi) coordinate
system to actual output pixel coordinate system.
NB! Getting only dpi_x and dpi_y is not sufficent for specific raster
output contexts, where we are actually interested in pixel boundaries.

Otherwise everything is cool.

Lauris