Some critics about Ubuntu / New Installing

[Colin Watson]

On Mon, Nov 29, 2004 at 02:22:20PM -0500, David Walker wrote:
> On 11/29/04 1:54 PM, "Nikolai Prokoschenko" <nikolai at prokoschenko.de> wrote:
> > The installer _has_ actually been designed from scratch. It's called the
> > Debian Installer and is pretty modular. It _will_ have a graphical
> > installer at some point of time - it would be just a frontend, like the
> > text-based is now. While integrating Anaconda would take much more time
> > than getting a gtk+-fb-gui to the d-i.
> 
> Anaconda was an example of what is out there.  Sure I don't think we should
> use it.  I worked with anaconda for a while and despised it, but it does the
> job.  Something like gtk+-fb would probably work with the FB, and never
> looking over d-i I don't know how that would work.

gtk+-fb is unmaintained upstream and didn't even build last time I
checked. gtk+-directfb is not part of mainstream gtk+, but has the
advantage of working. :-) I have a hacked-up build of d-i around here
that uses it and works.

The main issue is turning the relatively simple information provided by
debconf into a good graphical user interface, and that goes well beyond
just the mechanics of making the UI backend work. There's already a
cdebconf gtk frontend, which (after I hacked on it a bit to bring it up
to date and fix some left-over deficiencies) works and is usable in a
crude way. However, it's basically just the newt frontend with
different-looking widgets and mouse support, not a quality interface.

At the last conference, Joey Hess, Jeff Waugh, and I got together to
discuss a mechanism to hook glade designs into debconf, and we came to
the conclusion that it was not only achievable but surprisingly
straightforward as far as debconf was concerned. The main philosophical
question is whether to put the hooks in code (the "custom widgets"
approach) or in templates (the "hook one question and preseed the rest"
approach). The former has the advantage that it could provide things
like a better partitioner in the newt frontend as well, while the latter
has the advantage that it could theoretically be done with very few code
changes. I'm not sure we'll know which is best until we actually try
them out.

Cheers,

-- 
Colin Watson                                    [cjwatson at canonical.com]