Re: Debconf vs. graphical installer
One option is not to use Debconf for asking questions. Unfortunately
this means we have to support two installers -- graphical and text
oriented. Using something like configlets doesn't solve this problem
as the `config' script for Debconf and `main.py' for the configlets
solve more or less one task. The configuration of X gives us one
example for the difficulties: it is complex enough and it is not easy
to keep the X-configlet compatible with the X-Debconf dialog.
Another option is to extend the protocol. Unfortunately this again
has many disadvantages. I thing that it is not possible for Debconf
to be together 1. independent from any existing toolkits (gtk, qt,
gnustep) and 2. user friendly.
On 30.VII.2003 at 13:46 Sebastian Ley wrote:
> http://www.mmweg.rwth-aachen.de/~sebastian.ley/d-i/partitioner/partition.png
>
> As you would suspect there is no way to realize such a widget with the
> debconf protocol ;-)
I think there is a way to realize it without any change in the current
debconf protocol. :-) We only need a "smarter" frontend.
Some advantages: doesn't need any change of the current Debconf
protocol, is not gtk-centric, avoids maintaining two -- text and
graphical versions of the installer, can be used not only for the
installer.
Disadvantages: difficult to implement (?), supports only
Debconf-dialogs that are capable to backup.
I will demonstrate how this "smarter" frontend is supposed to work
using the partitioner as an example. The main window of the
partitioner has a browser for the devices and partitions and buttons
such as `Delete', `New', `Edit', `Finish'. We see that this window is
"responsible" for the following Debconf questions: 1. choose a device,
2. choose a partition/free space, 3. what to do with this
partition/free space. This window registers itself as responsible for
these three questions.
When the script of the partitioner asks the first question (choose a
device) the frontend popups the window. Then the "tree"-widget (for
the browser of devices and partitions) initiates a dialog with debconf
-- it chooses the first device and gets the second question (choose a
partition). At this point the tree-widget goes back, debconf returns
to the first question (choose device), the tree widget chooses the
next available device and so forth. Finally the tree widget will know
all available devices and partitions and the user will be able to
colaps or expand any branches of the partition tree.
After that, similar thing repeats for the other components in the
window. In our case we have a set of buttons. In its turn the set of
buttons initiates a dialog with debconf. The buttons are interested
of question 3, but the first question they get is 1. They know
however that the tree-widget is responsible for this question and ask
the tree-widget to answer it. The tree widget answers it accordingly
to the currently selected by the user item. The same happens with
question 2. Finally the buttons reach their question. It is a select
and each of the options (new partition, delete partition, etc.)
corresponds to some button. If there is no option for some button,
then it is shadowed so the user knows that he/she can not press it.
For example if the currently selected item in the tree browser is a
free space, then the button `Delete' will be shadowed.
After this happens it is time for the user to do something. If he/she
moves in the tree-browser, then the tree-browser will repeat the whole
before mentioned stuff with new answers of the first and the second
question. This will make some buttons to shadow and others to
unshadow. If the user presses the button `Edit', then the button will
answer to the question 3 accordingly. At this stage the partitioner is
going to ask new question 4. Our window is not responsible for this
question, so the frontend will popup a new window for it. Our window
has registered the option `Edit' as "non-final" and thats why our
window will not disappear but rather will serve as a parent window for
the new window. If the user presses `Finish', then the same thing
happens but in this case our window has registered this option as a
final, so the frontend knows that our window should disappear.
Whenever the partitioner asks a question that is different from these
3 questions, the frontend will open a new window for it; the only
difference is whether the current window will disappear or it will stay
temporary as inactive. If no window has registered itself for some
question, then the frontend will act as the current gtk-frontend.
Anton
Reply to: