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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
