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

Re: Debconf vs. graphical installer

* 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:

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:

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

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.


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

Reply to: