"Peter T. Breuer" wrote:
>
> "A month of sundays ago Helge Hafting wrote:"
> > >And in practice, users report a lot of "I want to turn on Feature Y but
> > >I can't figure out which Feature X enables it".
> >
> > One would really need two types of "if" for this to be sane. There is
>
> Lovely. "Usually if" and "sometimes if"! Or should be go to modalities?
> "Ought if" and "should if"!
>
> > no need to
> > show the DMA settings for each and every un-selected soundcard, for
> > example. But it
>
> You have seen xconfig, right?
Barely. It works for some kernel versions, and fail for others. And
requires
extra libraries for X that I don't have on all machines. And I do some
compiles without bringing up X first, so I use "make oldconfig" most of
the time,
and run "make menuconfig" whenever something new comes up, so I can look
at the help texts.
I realize that using two kinds of "if" isn't necessary after all. For
stuff that
fits in a tree structure - use the current approach and show only the
choices
where dependencies further up in the tree is satisfied. You need to
enable sound before selecting a soundcard - that is obvious.
I propose a different handling for items that have dependencies in other
branches:
Show them as soon as all dependencies in the same branch is satisfied.
If the user turns it on - give a confirmation message like "This also
require
features Z, Y, & Z, ok to turn them on? Y/N/M)"
Trivial cases can be answered with Y or M, N is used when the user want
to take
a closer look at what X, Y & Z are first.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:24 EST