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

[desktop] Configuration handling


I have been thinking for a long time about the confiuration issue. Most
people will agree that it really is the job of the distribution to
provide configuration tools, and not the job of desktop environments.
However users expect their configuration tools to be integrated in their

On one hand, configuration tools built by desktop environments are
integrated, but they may not fit in the distribution's philosophy. On
the other hand, configuration tools built by the distribution are
integrated in the distribution's philosophy, but lots of hard work is
required to give multiple 'look & feels' to fit the tools to all
environments available. Moreover this work has to be done again each
time a new type of environment appears, otherwise frustrating its users.

We already have a tool that could solve these problems : debconf. It is
very well integated and able to adapt itself to different looks (curses,
text only, GTK ...). But I think it is not advanced enough to satisfy
GUI users : it is really difficult (impossible ?) to produce the rich
dialog boxes they expect.

With a 'Debconf II' project, we could give the configuration problem a
smart solution. It could work as following :
- An abstract description of the data & actions we want to get from/tell
  to the user
- Some process to translate this description into the real UI, depending
  on some environment variable (for example)
- A hinting mechanism to help the translation process when it has to
  make decisions in GUIs, for example, and specific hinting data for
  each specific UI type (the more we get specific, the less data should
  be given). In this category falls the localization data, with a
  different set of data for each locale.
- The ability for the users to override hinting mechanisms, to let them
  adjust the 'look & feel' of the UI to what they like (I mean the
  translation process may choose to use radio buttons where the user
  prefers dropdown lists, so it could be worth letting the user change
  this if he/she wishes).

I would be glad to discuss this further if you are interested, since a
'Debconf II' project could have much more implications in Debian and
maybe GNU in general, by enabling developers to write cross-UI apps
(including graphical, textmode[allowing scripting], web/html, and even

HAESSIG Jean-Christophe

Reply to: