Re: Debconf vs. graphical installer

[Alastair McKinstry <mckinstry@computer.org>]

On Thu, 2003-07-31 at 23:34, 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
> > ...
> > 
> > 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. 
> 
I think it is critical that we finish d-1 v1.0 with the current design. 
Releasing sarge is becoming urgent: woody does not contain drivers for
an increasing number of new systems, and becomes unusable because of it
(eg. recently I had to install woody on a  new Dell box with e1000. No
support in the CDROM kernels, which meant I had to hand-hack a CD with a
new kernel before networking would work. Painful, and not something we
could foist on users for long.) Stop-gap releases of boot-floppies won't
work: we need to get d-i to the point where we can release sarge ASAP,
and that means feature freezing now, without a graphical install. Plan
for v2.0, but work on the current code.

> 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

Yes; we may reconsider the small X server for other reasons: many archs
dont support directfb, and a tinyX is not too large. As shown in current
builds, switching front-ends is not a big deal: We can live with a 2.8
MB boot image in the CDROM that loads and switches to the graphical
installer from the CD quite straightforwardly.

Apart from "GUI-optimised udebs" for use in a graphical installer 
(eg a partitioning udeb that puts up something like mandrakes
partitioner), we can also improve the installer by replacing main-menu
with gui-main-menu in the graphical case: eg putting the main menu along
the side, at the same time as the debconf dialogs in the centre of the
screen, showing tasks to do and tasks not yet done (in different
colours, ticked off , etc).

-- 
Alastair McKinstry <mckinstry@computer.org>
GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC  1020 FA8E 3790 9051 38F4

He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty he establishes a precedent that
will reach to himself.

- --Thomas Paine