From: Matthias Schniedermeyer <ms@citd.de>
To: Bernd Petrovitsch <bernd@firmix.at>
Cc: Sam Ravnborg <sam@ravnborg.org>,
Roman Zippel <zippel@linux-m68k.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: kconfig - a suggestion how to fix the select issue
Date: Sun, 4 May 2008 19:59:13 +0200 [thread overview]
Message-ID: <20080504175913.GA28072@citd.de> (raw)
In-Reply-To: <1209895922.4114.21.camel@gimli.at.home>
On 04.05.2008 12:12, Bernd Petrovitsch wrote:
> On Sun, 2008-05-04 at 09:10 +0200, Sam Ravnborg wrote:
> > Today we have two ways to express/solve dependencies.
> >
> > Top-down we have "depends on"
> > and bottom up we have "select".
> >
> > The "depends on" dependencies at the same
> > time impact the visibility of a symbol.
> > A symbol with "depends on" not satisfied are not
> > visible and thus not shown in menuconfig.
>
> Perhaps this is problem: The menu item shouldn't be selectable for sure
> but it may well be visible (and I'm purposely ignoring details of "how
> to grey out" for the different user interfaces).
> If it's visible (but not selectable) the user interface can provide the
> auto-generated requirements (derived from the "depends on" chains) as
> part of the "help" or where ever it seems useful. And the user at least
> knows where to look further.
I always wondered why there is no "grey out", at least optionaly.
My "favourite"(tm) example of a sub-marine is: Wireless drivers (mac80211).
The config-option to switch on the visibility of the mac80211 drivers
("CONFIG_MAC80211") is conveniently located on the other side of the
milky way.
(3 menus down, a sitestep and 2 up again. At least in menuconfig)
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
next prev parent reply other threads:[~2008-05-04 18:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-04 7:10 kconfig - a suggestion how to fix the select issue Sam Ravnborg
2008-05-04 8:11 ` Adrian Bunk
2008-05-04 8:27 ` Sam Ravnborg
2008-05-04 9:04 ` Adrian Bunk
2008-05-04 10:38 ` Sam Ravnborg
2008-05-04 11:55 ` Adrian Bunk
2008-05-04 12:17 ` Sam Ravnborg
2008-05-04 12:57 ` Adrian Bunk
2008-05-04 12:37 ` Oleg Verych
2008-05-04 10:12 ` Bernd Petrovitsch
2008-05-04 17:59 ` Matthias Schniedermeyer [this message]
2008-05-04 12:55 ` David Collier-Brown
2008-05-04 15:01 ` Oleg Verych
2008-05-04 19:28 ` Rene Herman
2008-05-04 19:32 ` Sam Ravnborg
2008-05-04 20:14 ` Bernd Eckenfels
2008-05-06 8:19 ` Jan Engelhardt
2008-05-06 15:52 ` Oleg Verych
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080504175913.GA28072@citd.de \
--to=ms@citd.de \
--cc=bernd@firmix.at \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.