[Gnome-print] what's happening in HEAD

[Lauris Kaplinski <lauris ximian com>]

Hello!

My short report, what is happening in gnome-print HEAD.
As you know, it is now "officially" unstable. It used not to compile for
long time - now that should be fixed, but everything is broken in other ways.

1. Backbone cleanup
I did a extensive surgery on GnomePrintContextClass, dropping most of virtual methods.
The remaining ones are:

- beginpage (pc, const gchar *name)
  Unlike for previous versions, calling beginpage mandatory, and printing operators
  fail without it
- showpage (ps)
- gsave (pc)
  I still do not have idea, what to do with that. probably I'll rename it to something like:
    bind (pc, gdouble opacity, const ArtBpath *clip)
  as it is currently needed only for maintaining clip paths
- grestore (ps)
  Same.
- clip (pc, const ArtBpath *path, ArtWindRule rule)
  Sets clipping path. If gsave will be replaced with bind, it will probably be removed
- fill (pc, const ArtBpath *path, ArtWindRule rule)
  Paints filled shape. Currently it gets graphic style from GPGC object of printcontext,
  I plan to add style explicitly (but it needs a bit thought to design style object)
- stroke (pc, const ArtBpath *path)
  Paints line. Derives also style (including dash) from GPGC
- image (pc, const double *affine, const gchar *pc, gint w, gint h, gint rowstride, gint channels)
  Paints raster image. There has to be something better instead of channels - like
  colorspace object or so.
- glyphlist (pc, const double *affine, GnomeGlyphList *gl)
  Paints rich text (different fonts, colors, glyph placements)
- close (pc)
  Closes context. Calling close is mandatory - whether print job is discarded or not
  without closing it, is undefined.

The frontend remain the same, i.e. there will be wrapper and convenience methods implementing
old familiar painting operators (moveto, lineto etc.).

2. Separation of libgnomeprint and libgnomeprintx
These are built separately at moment. Some hackish code is shared at moment, until I
find the right palce for it.

3. GnomeprintRGBP does not depend on canvas any more. It uses now GnomeprintMeta +
GnomePrintRBuf - which makes it possibly slower, but releases the GtkWidget dependency.
It has to be rewritten in future with display lists, but that is not top priority.

4. Configuration abstraction
I am at currently building abstract configuration frontend to everything. It uses Chema's
libgpa as backend - but can have different ones - such as OMNi dynamic configuration
system.
The basic configuration object is opaque GPANode. GPANodes make up tree, where branches can
be accessed with string keys, like
"Settings.Output.Paper.Form"
Either by value, or as branch node.
Existing opaque objects (GnomePrinter) will be typedefed to GPANode.
The single GPANode (the root of configuration tree) will be given as argument to all
setup dialogs and widgets, and finally as argument to printcontext creation.
Configuration widgets manipulate the internals of tree with lightweight API, and can
bound listeners to mutation signals - so changes done by one widget will propagate to
others.

API so far:

- GPANode *gpa_defaults()
  Create new tree instance with default settings
- GPANode *gpa_node_get_child (node, GPANode *previous)
- gchar *gpa_node_get_value (node)
- GPANode *gpa_node_get_path_node (node, const gchar *path)
- gchar *gpa_node_get_path_value (node, const gchar *path)
- gboolean gpa_node_set_path_value (node, const gchar *path, const gchar *value)

path is dot-separated sequence of child names, like
- gpa_node_get_path_node (config, "Globals.Printers")
  return reference to printer list node
- gpa_node_get_path_value (config, "Settings.Output.Paper.Form")
  returns paper size as string ("A4", "Letter")
- gpa_node_get_path_value (config, "Settings.Output.Paper.Form.Width")
  returns paper width as string ("1520")

There is single signal "modified", but I have to add more.
Also notice, that tree is probably quite dynamic. I.e. separate child and attribute nodes
will not be created, unless user asks for them explicitly - and will be discarded, if
user drops refcount. So although there may be paths "Resolution", "Resolution.DPI",
"Resolution.DPIX", "Resolution.DPIY", "Resolution.Affine", the settings node contains
only single value (or pair of values more exactly).

Now the fun stuff:
There is abstract base class for printing configuration widgets (GPAWidget). It is
subclass of GtkBin (i.e. can contain whatever single children), and is bound to
certain GPANode instance.
Widgets currently in work, that are derived from GPAWidget:
- GPAPrinterSelector (simple menu)
- GPASettingsSelector (simple menu)
- add_printer and add_settings dialogs
- GnomePrinterWidget (contains printer and widget selectors)
- GPAResolutionWidget

So, configuration is done the following way:
- get configuration node (either default or load per-application saved one)
- build all configuration widgets/dialogs, binding these to given node - they will
  update themselves automatically from signals, so you do not need any modality
- if configuration is completed, give the same configuration node to
  gnome_print_context_new (node)

1st tier TODO list:
- Finish preliminary configuration abstraction
- Write most important GPAWidget subclasses (paper, copies...)
- Write OMNi integration code, so we can derive configuration dynamically from OMNi library
- Port TrueType support from libgnomefont
- Clean up (and break ;-) more old stuff

Best wishes,
Lauris Kaplinski