On May 15 2007 08:04, Satyam Sharma wrote:
> On 5/15/07, Jan Engelhardt <[email protected]> wrote:
>> that can be switched on or off.
>> It is for those people that start with an arbitrary .config and
>> work their way through menuconfig to disable all the parts they
>> do not want. So, point no. 1:
>>
>> * Disabling this menu disables all the fluff inside it,
>> without needing to enter the menu and disable each
>> option one by one (as was the case previously)
>
> This kind of promise was really nice, and why I liked Jan's
> menuconfig patches a lot.
>
> But if:
>
> On 5/15/07, Tilman Schmidt <[email protected]> wrote:
>> Another essential piece of information. I seem to remember other
>> menus which, when disabled, kept the selection status of the
>> options inside and just hid them from view.
>
> is true, then are we really gaining much from these configmenu's?
If you transform a menu with hidden options (which do NOT "depend on"
the menu - they can't even) into a menuconfig (continuing not to
depend on the menuconfig), the presentation fucks up (especially in
ncurses-menuconfig). That is a good hint something should be taken
more seriously.
So, for menus with hidden options I had a number of options how to
go about them:
- move the hidden options before the menuconfig or after, so
the presentation does not bork;
- leave the menu as-is because there's just so many hidden
options and a menuconfig entry is detrimental
> [unrelated]
> I wish these new constructs were called "configmenu" and
> _not_ "menuconfig". It causes confusion with the "menuconfig"
> master Makefile rule which has nothing to do with these new
> "configmenu"s.
> [/unrelated]
Indeed.
>> Then of course, one can also turn these menuconfig on (apparently!)
>> to be able to descend into them and select some drivers they like.
>> Point no. 2:
>>
>> * Since Jens Axboe's stance ["default y idiocy"] is to have
>> these menus disabled by default, people should most likely
>> enable them first before they will be able to enter them.
>
> I do agree that anything non-essential (even if it's just a presentation
> menu that doesn't affect builds) must be default n.
>
>> (I would have wanted them to be always 'y' - it does not affect
>> the build, just opens all menus by default)
>
> IMHO, the real problem with "default y" menuconfig's, is that they
> cause unpleasant surprises to those folks that use the text-based
> "make oldconfig". They get confronted with choices that they never
> bothered about (or even knew existed) previously, and have no
> idea how to answer them -- same problem faced by Tilman, when
> he used oldconfig.
>
> I think what happened here is that Jan really only considered the
> "make menuconfig" users with these new constructs (which makes life
> really simple for them), but "oldconfig" users were unfortunately in for
> unpleasant surprises ...
I can't tell, since I'd just say yes if it asks "Ethernet (10 GbE)?" -
either I have such an adapter or I don't.
So what do we need?
* 'configmenu' option (with 'endconfigmenu') that works the same as
'menu' and 'endmenu' (so we can have hidden options), but at the
same time make the ---> and options inside it disappear when it is
not selected. Currently, no other type seems to satisfy this.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
