[Gnome-print] Gnome-print/bonobo-conf (Was: Re: [Labs] Status report)

[Lauris Kaplinski <lauris ximian com>]

Hello Dietmar!

I took a liberty to cc it to some relevant lists, as after having
thought about it (and reading the endless GConf/bonobo-conf) thingie,
I feel myself quite idealess.

The general idea to have same configuration mechanism for printing
as for everything else, seems exactly The Right Thing To Do.

Now, Chema and I have put quite a lot of thoughtwork into gnome-print
configuration system. And I have bad feeling, that my current
design does not translate exactly to bonobo-conf (i.e. PropertyBags).
So if you can find a some hours, maybe you can say your opinion
about these issues.

A.
Current configuration schema is modelled loosely after DOM, keeping
an eye on compatibility with possible full DOM implementation.
Personally I still find DOM excellent general model, although
spec is waaay overcomplicated.

B.
There are 2 conceptually different layers (that I have unified under
single API, but that is no problem - they may be broken away again).

Models - (basically static) XML trees, defining available configuration
options. These probably do not belong to bonobo-conf scope, as these
are not intended to be changed by application - only by specific setup 
tools.

Printers - printer conf is xml tree, pointing to given model object, and
defining list of settings (selected values for model options). It would
be useful to represent settings by bonobo-conf, especially as things
like default paper size may be of interest by quite a large audience.

Now, one problem is, that settings are completely dynamic. We
will set up certain collection of standard paths, like
Output.Media.PhysicalPage
But each and every model may have completely private paths. To make
advanced editing of nonstandard printer parameters possible, one has
to have a way to discover all paths in model definitions. My current
API uses gpa_node_get_child to enumerate all children of given node
(DOM-like approach).

Also keys are tied together by many connections (like parent-children
relationship and constraints). I.e changing certain value may result
in extensive change in many configuration values. The extreme is my
current approach to choosing printer, where you basically set:

  gpa_node_set_value (config, "Printer", "MY-PRINTER-ID")

And all configuration tree changes, as new settings are loaded from
new printer definition file.

I cannot tell, how much such behaviour can be emulated by PropertyBags.
But interconnection is certainly needed thing.

I see 2 ways to resolve this:

1. Use PropertyBags to save individual keys, but implement frontend 
layer, that does interconnection thingie. It does not seem meaningful,
as there has new API layer anyways, so bonobo-conf will be hidden.

2. Implement specific backend, so we could use bonobo-conf for
setting and querying keys, which would look like something
"gpa:Output/Media/PhysicalPage"
This involves lot of work, but seems to be meaningful solution to me.
Remains a question, whether and how application can discover available
keys. What comes to mind, is querying key for "Children" property,
which gives us list of PropertyBags. Each one will then have a
property called "Id", so:
"Parent/Property/Bag/Path" . "Id" == child property bag path (OK we 
already have child, but it may turn useful to have it later).
I am a bit worried, how much CORBA calls even simple DOM operation
may take - probably it is not problem.

Then, there are many-many independent trees of settings - many printers,
and each printer may have many complects of settings. Choosing and
modifying one should not affect other applications, unless user
forces these as defaults. This can probably be resolved in different 
ways, like prefixing keys by printer/settings id.

Also, I very much like to have bubbling events. I.e. I can catch
mutation events on parents, that signal me, if children change. It
saves lots of event handler setting/clearing in UI code.

Any ideas?

Lauris Kaplinski

On 10 Jun 2001 11:09:55 +0200, Dietmar Maurer wrote:
> Lauris Kaplinski wrote:
> 
> > Hello!
> >
> > Configuration widgets are things like paper-selector, resolution
> > selector, printer selector...
> >
> > My idea is to have single configuration object (and it is mostly
> > implemented too) GPAConfig (actually abstract base class
> > GPANode is used in API), and derive selectors from generic
> > base class GPAWidget.
> > GPAWidget binds to GPAConfig, reads and writes values from/to it,
> > and acts on mutation signals, if needed.
> >
> > So, to compose application-specific configuration widget, you:
> > 1. Get default or saved configuration
> > 2. Create container widget and structural containers
> > 3. Create as much conf widgets as you need, binding these to config
> > 4. Put all these to container
> > Or, if you want, you can make you widget as a whole a subclass
> > of GPAWidget, so it can be re-used in similar way.
> >
> > So there is single, generic API to all configuration widgets.
> > So, if your application wants to replace some system configuration
> > widget, it can do that in defined way, and it can be substituted
> > seamlessly into composite widgets. Or - printers may have specific
> > configuration stuff (fax is one good example).
> 
> Ok, I do not understand everything, but I think I can see some similarity
> to PropertyEditors (bonobo-conf). A PropertyEditor is a widget which
> read/writes values directly into a configuration database, and acts on
> mutation signals if needed. You can find an example on how to use
> PropertyEditors in bonobo-conf/examples/evolution-calendar-config.c
> 
> I wonder if it is feasible to use bonobo-conf to store the printer
> configuration. The advantages would be:
> 
>     - unified configuration storage (can be edited with a generic
> configuration editor)
>     - we can use the bonobo-conf framework (PropertyEditors) to create
> configuration dialogs
> 
> What do you think?
> 
> - Dietmar