[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

* 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: