future of gconf
- From: "Sergey V. Spiridonov" <sena hurd homeunix org>
- To: gconf-list gnome org
- Subject: future of gconf
- Date: Tue, 15 Jul 2003 15:53:22 +0200
here are some ideas concerning gconf project and some experience, which
I hope will be useful.
One year ago a read gconf documentation and like its idea very much.
Unfortunately the company where I worked was not able to use gconf
because of the licensing issues. But I use gconf ideas and find out
that they work very nice. I think it is time to give back some of the
experience I got from implementing some of the gconf ideas. Hope they
will be useful for the gconf developers. Hope I will find a time to
contribute also some code to the gconf. Please note: I am not gconf or
gnome developer, but I want to become one. Everything I know about gconf
is documentation from gnome.org.
To help understanding what I will talking about, I have to describe the
area where I tried to implement some of the gconf features. We have a
bunch of engines which perform some useful tasks and another bunch of
the main applications which perform engine initialization, control and
user interfacing. Both engines and main applications have configuration
parameters. Engines are runnable on various platforms (including for
example DSP). Sometimes main application is a daemon without user
interface (UI). That's why there there was a need to have full-featured
setup tool (a-lya gconf-edit) to configure engines without UI.
2. Extended constraints.
What I like in gconf most of all is standartization. Strandart API,
standart notification mechanism, standart backend(s). I hope, one day in
the far future we will forget about the /etc nightmare . There is one
step which is still not done: standart server-side language. It is
needed to have extended constraints for configuration parameters. Simple
example: we have parameter A, B, C and there is a need to be sure that A
is always less then B+C. In this example the constraint "A<B+C", should
be checked each and every time when A, B, C parameters are updated.
Why server-side? Of course, this check can be done in application, but
it is too late in case we use gconf-edit. The check should be done
*before* the "wrong" value will be stored in database. Most of the
modern databases have constraints and triggers. They are used for values
validating on the server side.
Which language should be used for this standart? I don't care too much.
I think guile is O.K. for such a task. I like guile and it is default
GNU extension language.
Server-side language feature depends also on the transaction
functionality. I have no idea, on which stage it is in gconf. If we will
check an example above, there is a need to have something like "start
transaction"-"A=1, B=2,C=3"-"commit work" scheme.
In our project we implemented a kind of such a language.
3. User interface. (UI).
Another problem we faced with is not solved in gconf. It is UI in the
standart setup tool. We moved parameters integrity checking into the
server-side. The next step was to implement full-featured "configurating
tool". What is "full-featured"? I mean all this "stupid" check-boxes,
sliders, frames, tabs, dialogs in the "usual" application configuration
dialog.... AFAIK, gconf-edit uses regedit-like tree widget and standart
dialogs which are binded to the parameter type.
What can be done here? Well, here is how we solved it: we describe all
this dialogs, tabs, checkboxes in XML and store this description
together with configuration database. And it works!
Let's imagine, the same is done for gconf. Applications install XML
description of configuration dialogs together with parameters. From this
point gconf-edit can look like the same as if you will open application
configurating dialog. Application itself can use this UI descriptions,
stored in the gconf database to buiild UI configuration dialogs
"automagically". Together with server-side language with triggers, we
will have full-featured "configurating tool" (gconf-edit), which will
provide UI, which is designed by the original application developer.
It's not everything I want to say about gconf, but it is enough for one
mail. I would like to do something in this area and hopefully I will get
a timeframe to work on this.
Thanks for taking time to read my mail, I know my English can be
improved a lot
Best regards, Sergey Spiridonov
] [Thread Prev