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