* 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 capabilities. 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 possible. Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
