[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0709162106280.1817@scrub.home>
Date: Sun, 16 Sep 2007 21:36:54 +0200 (CEST)
From: Roman Zippel <zippel@...ux-m68k.org>
To: Matej Laitl <strohel@...il.com>
cc: Sam Ravnborg <sam@...nborg.org>,
Randy Dunlap <randy.dunlap@...cle.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] menuconfig: distinguish between selected-by-another
options and comments
Hi,
On Sun, 16 Sep 2007, Matej Laitl wrote:
> The v2 was maybe more intuitive, but had at least one flaw, where it claimed
> the option was selected by another, while it was in fact only made
> unchangeable by 'bool "Enable block layer" if EMBEDDED', defaulting to y.
The point is that I'm getting more concerned about overloading the
interface with nontrivial information.
Another direction to consider would be to add this information to the help
text, e.g. choose one syntax for nonchangable symbols and then the user
can press help to find more detailed information.
> > This maximum value is overridden
> > by the minimum value, so I wouldn't like it to be exported like this.
>
> Where exactly does this happen?
sym_tristate_within_range() checks whether the new value is ok and
sym_calc_value() uses rev_dep to override the value when necessary.
> There are cases when maximum < minimum, for
> example when you <M> THINKPAD_ACPI, then <N> BACKLIGHT_LCD_SUPPORT. After that,
> BACKLIGHT_CLASS_DEVICE has minimum of 1 (selected by THINKPAD_ACPI) and maximum
> 0 (depends on BACKLIGHT_LCD_SUPPORT, which is n)
The actual maximum value is then 1.
> The function names are maybe suboptimal, I agree.
The variable name is already correct, it's the visibility value of a
symbol not its maximum. In the case of the "if EMBEDDED" then individual
menu entries can still be visible, if any child entry is visible (see
menu_is_visible()).
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists