Re: Debconf vs. graphical installer
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
> ...
>
> These are still sufficiently abstract for use on character terminals as
> well as frame buffers, but allow you to build higher level widgets
> (partition selectors) independently from the rendering backend.
I don't think this is the way it is best done. Basically this boils down
to extending the debconf protocol. 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. Abstraction generally is a good thing(tm), but to
design a nice GUI that is really easy to use, you have to have all
aspects of GUI creation under your control. It must be possible to
design the widgets and combinations of widgets yourself.
I like sebastians proposal of having frontends in librarys for every
configuration udeb. But I see, that this will be a hughe task and I'm
not sure if it wouldn't be a better way to finish the installer with the
current design and afterwards design a better solution than debconf for
user interaction for d-i v2.
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. 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. To fully automate the
installation until after anna when installing from cdrom. This way we
could overcome most of our diskspace limitations and also use XFree86.If
someone wants to load special non-default installer modules, he could
run anna a second time.
gaudenz
Reply to: