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 <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
