* Sebastian Ley wrote: > here we go to add some discussion on the never ending topic of a > graphical installer. The current implementation of the gtk-frontend > for cdebconf is highly unsatisfactory. Because of the limited debconf > capabilities it is a mere question asker which is not what one would > expect from a graphical installer. Okay, perhaps I sould elaborate on this a bit more to raise your interest in this topic ;-) As most of you know the current design implies that all (or at least most) user interaction will be handled by cdebconf. This leaves us with certain restrictions, we can do nothing more than sequentially asking questions of predefined types: string, select, multiselct, boolean (which are the most important ones). It is not difficult to implement these questions for a gtk frontend. I did this some time ago and the result looks like this: http://www.mmweg.rwth-aachen.de/~sebastian.ley/d-i/screenshots/select-modules.png http://www.mmweg.rwth-aachen.de/~sebastian.ley/d-i/screenshots/choose-mirror.png However this is not what one would expect from a graphical installation. Gtk has more powerful options and it would be desirable to use them. For instance I got a screenshot from a graphical partitioner (alpha stadium) based on gtk2: 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 ;-) As in my opinion a graphical installer ist highly desirable, we need some idea how to overcome these shortages of the debconf protocol while at the same time not being too intrusive with d-i's current architecture. There were already some ideas, which might be a good starting point for a discussion: - Modules should be able to provide special widgets for different frontends which can be loaded as shared objects by cdebconf. E.g. a partitioner would then install a file /usr/lib/cdebconf/widgets/gtk/partitioner.so which could then be loaded by cdebconf. It would add a new question handler which, when invoked, gives control to the widget's code. It is then responsible for all further actions. - Especially for the gtk frontend we thought of a solution to use glade files to specify custom widgets and then use libglade in d-i to display them at runtime. Seems a little complicated though... - Instead of glade we could invent a new widget describing language. This could also be a general enhancement of the debconf protocol, other frontends could use these information to create custom widgets (using the CAPB command to indicate if a frontend supports it) - Here could be your idea! I would be glad if there was some discussion about this. Regards, Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
Attachment:
pgpe3OEZlvYaa.pgp
Description: PGP signature