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

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


PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Reply to: