Re: Debconf vs. graphical installer
* Gaudenz Steinlin wrote:
> Am Mit, 2003-07-30 um 17.47 schrieb Emile van Bergen:
> > Wouldn't it be better to create a wire (pipe) protocol for slightly
> > lower level widgets, such as
> > 1. button
> > 2. scroll bar
> > 3. list
> I don't think this is the way it is best done. Basically this boils
> down to extending the debconf protocol.
Yeah, this is what I had in mind with my third option.
> But I think what sebastian addresses are inherent limitations of
> every such protocol. You can't design a really usable GUI with
> abstracting from the GUI toolkit (GTK, QT, Whatever) to use.
Yes and no. It is a tightrope walk between creating a frontend
agnostic interface and the wish to get most out of each frontends
The first claim was a central design criterium for d-i. Moving away
from it would involve to trash many months of work and will add much
work until finishing d-i.
> I like sebastians proposal of having frontends in librarys for every
> configuration udeb.
The more I think of it, the more I start to dislike it ;-) Imagine how
much work it really is to do such a thing. There must be
#udebs x #frontends of custom widgets. If a change in the module
involves a change in the UI, all frontend widgets must be changed. I
don't know if that is feasable...
> One other think, related to graphical installers: I looked at some
> other graphical installers (Mandrake, YellowDog, SuSE, RedHat) and
> they all use XFree86 instead of directfb.
Switching to an xserver is still in consideration.
> They manage to load the second stage of their installer (when used
> from cdrom) without user interaction. I think it would be great to
> have the same thing in d-i.
Heh, you better have a look at d-i. With priority = critical and an
appropriate image, you can do an install with only having to answer
three questions. It is one of d-i's goals, to automate as much as
Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6