Below a reply to a very old post from Joey [1] to which I should have replied then, but never got around to. I've quoted his mail in full for context. [1] http://lists.debian.org/debian-boot/2008/05/msg00345.html On Thursday 08 May 2008, Joey Hess wrote: > A long, long time ago I proposed changing the main menu into a kind of > list of settings like this. > > Language: English > Location: United States > Network: autoconfigure > Disk: autopartition entire disk (hda1) > Users: root, joey > Software: desktop, print-server > Grub: install to MBR, no other OS > Finish installation I get the idea, but I don't really see the implementation. For a lot of components I just don't see how you could usefully translate them into a value and there's also the problem of limited line length. > Select a menu item to configure it, thereby running the menu item > at medium priority, or skip over it if the default setting looks good > (and skipped over menu items would run noninteractively at high[1] > priority as needed to satisfy dependencies). > > Once you have such a menu, it's easy to add things to it, without them > getting in the way unduely. As long as there arn't *too* many. > > Language: English > Location: United States > Mouse: PS/2 > Theme: foo > Network: autoconfigure > Disk: hda1, autopartition entire disk > Users: root, joey > Software: desktop > Grub: no other OS > Finish installation > > Expert mode: disabled > Rescue mode: disabled > > Of course, submenus could also conceivably branch off of this. installer-settings essentially implements a submenu. I also feel that the implementation I have now is one that does not get in the way, especially since it is only really used if the user selects expert mode, so basically he gets what he asks for. For the graphical installer it would be great if an alternative "menu bar" kind of interface could be implemented. > Frans Pop wrote: > > Overview of potential settings > > ------------------------------ > > * General > > - show expert questions (in "early") > > - debconf priority (in "menu") > > - rescue mode (in "early/additional") > > - frontend theme > > - mouse support (device/protocol/left-handed) (in "early/menu") > > Having these things in a submenu makes sense, I think, both in the > current installer, and in the context of the above wild idea. > > > * Hardware support > > - SATA RAID > > - multipath > > - PCMCIA support (could help avoid asking multiple times!) > > * Networking > > - PPPoE support (in "early") > > - type of configuration (none/static/dhcp) > > - allow unauthenticated (?) > > * Installed system > > - use SUDO instead of root account > > - create first user > > * Debian settings (or Package management) > > - use security (?) > > - use volatile (?) > > - use contrib (?) > > - use non-free (?) > > * Advanced > > - keep regular virtual consoles (sercon installs) > > - eject CD > > - halt/poweroff system instead of reboot > > I'm not convinced that it makes sense to have a menu with these things > on it, rather than just asking the questions at relevant times with > appropriate priorities. For a number of them I'm inclined to agree. We will have to be very careful about which we do and which we don't select. But I also feel quite strongly about keeping the "number of times to hit enter for a full install" as low as possible. And there are some options that IMO really should be more easily accessible to users, *without* forcing them to go through _all_ possible dialogs and permutations. One example is the "eject CD" option. This really does cause problems sometimes, but not enough to warrant an extra dialog during finish-install warning that the CD is about to be ejected. Currently the only way to prevent CD ejection is using a boot option, which most users don't know about and which you have to remember at a time that your mind just isn't on that stage of the installation. Having it as a setting "Eject CD at end of install" means that users will both have an easy way to change it _and_ have a visual reminder. > To what extent are the problems this is trying > to solve due to us having gotten into the bad habit of adding debconf > settings but never actually displaying a question for them? AFAIK we've only done that for functionality that is still experimental. It's always been the intention to make them properly accessible, or to support them by default, once better implemented. ATM both dmraid and multipath still rely on very crude bootloader installer support. More general, for support of things like PPPoE, dmraid and multipath the installer can IMO go two ways: 1) support by default, which means additional memory usage and potential failure modes; 2) offer it as optional functionality. Given that all three are only relevant for a fairly small subset of users, I feel that the second option is quite realistic. But neither forcing those users to the current expert mode and thus also get all other confusing low prio dialogs, nor asking them to pass a boot parameter, are very nice. installer-settings provides a way to enable such options while still essentially doing a "normal" installation. You still need expert mode, but you get something that is a lot more flexible. If desired it should even be possible to have installer-settings offer _only_ such optional features during a default install. > It can be annoying to have to go through the installation at low > priority to be able to answer a single low-priority question, but this > menu does not, and cannot, contain every possible low-priority > question, so it doesn't eliminate that annoyance entirely. And in cases > of UI changes like these, it often makes sense to do the whole change, > or no change; leaving things in a half-way state means added > complexity. I don't agree with this. installer-settings is very definitely NOT intended to replace all medium or low priority questions. It is intended to implement choices that make sense as a _setting_, a way to configure the behavior of the installer rather than to make installation choices. > PS, why do we need to worry about which hand the mouse is configured > for? AFAIK the GUI frontend only uses a single mouse button, so why not > treat left and right clicks the same? If anyone knows of a way to tell gtk to behave that way, that would be fine with me.
Attachment:
signature.asc
Description: This is a digitally signed message part.