Re: redesigning the debian installer
Adam Di Carlo wrote:
> I like this scheme but I was kinda scratching my head wondering how
> device autodetection would work. I suppose that would just be a
> package, say, libdetect, which when you run the configure step, would
> emit information on possible network devices (including hopefully
> capability to do null serial install, plip, as well as more
> conventional network stuff), possible target devices, possible install
> media, even possible "input" devices (normally console or fb or even X
> or gecko perhaps, but also could be serial, or some automated system)?
>
> Is this along the lines of your thinking?
More or less. I don't think libdetect can handle all of the network
stuff though.
> The question would become how is this information emitted and what
> protocol is established for other pkgs to use this.
One option is just to let things link with libdetect and use its
interface to probe for things as needed. This helps limit probing for
one thing.
Another approach is to write the data to a file somewhere in some
parsable format.
> Stepping back, is there any other systems (in Debian or in the wider
> world) which use this sort of modular schema to drive a user
> interface? I'm a little worried that the structure of it might limit
> what we can do ergonomically to make the user interface a nice
> experience.
I guess I read this about 5 days ago, and I've neen pondering it. Some
examples:
* The web. Some people consider this a user interface, and it's
certianly modular. It's also hell from a UI design standpoint, IMHO.
There's little consistency between modules (websites). Without
resorting to nasty stuff like javascript, there is no way to implement
stuff like callbacks that respond to what you're doing when you do it
(for example, if you're filling in network info, a callback could
autocalculate your netmask from your ip address as you type it)
-- nothing happens until you take action to submit a form or go to the
next page.
* Debconf in Debian proper. If all you've seen is the dialog frontend in
potato, you don't know how nice and usable a debconf frontend can be
-- check out the slang frontend in woody (which actually still needs
a bit of UI work). You move from module to module pretty seamlessly.
Like the web though, debconf lacks the ability to use callbacks to make
the UI respond to you -- nothing happens until you move on to the next
question. This is the main reason I don't think we can use debconf as
the UI for the partitioner, which I think is the most UI-demanding part
of the install.
I don't think modularity is really the problem though. It's that both
the web and debconf abstract the UI to a certian degree, and with that
abstraction comes a loss of control or even knowledge on the part of the
html writer/programmer about what the UI will look like. It's a tradeoff
of course.
--
see shy jo
Reply to: