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

[Dietmar Maurer <dietmar ximian com>]

Lauris Kaplinski wrote:

> 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.

Yes, if possible.

> 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.

yes.

> 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"

That seems more reasonable.

> 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).

No, please use the ConfigDatabase interface instead (in Gnome 2, a
ConfigDatabase is a hierarchical PropertyBag, and that is what you need).

> I am a bit worried, how much CORBA calls even simple DOM operation
> may take - probably it is not problem.

Don't know that. But is it still necessary to use DOM if you switch to a
ConfigDatabase (you have a tree and you have notifications - but maybe DOM is
a bit more?)

> 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.
>

The event model is quite flexible in bonobo-config, and you can listen to
anything you want.

Does that help?

- Dietmar