future of gconf

Hi ,
here are some ideas concerning gconf project and some experience, which I hope will be useful.

1. Introduction.

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]