[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a781481a0705151852x2786c0d7sc6a9b6b2a3695ca6@mail.gmail.com>
Date: Wed, 16 May 2007 07:22:42 +0530
From: "Satyam Sharma" <satyam.sharma@...il.com>
To: "Jan Engelhardt" <jengelh@...ux01.gwdg.de>
Cc: "Tilman Schmidt" <tilman@...p.cc>,
LKML <linux-kernel@...r.kernel.org>,
"Stefan Richter" <stefanr@...6.in-berlin.de>
Subject: Re: Linux 2.6.22-rc1
On 5/15/07, Jan Engelhardt <jengelh@...ux01.gwdg.de> wrote:
> [...]
> 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.
Sorry, I didn't follow this "hidden options" thing at all ...
> 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
... but the second method seems sane and safe, still :-)
> 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.
(Yes, and with that implicit if-endif block to make "depends on" the
configmenu for those config options that are inside it automatic)
* Also, some "[MENU]" kind of prefix/tag in the text of configmenu
options would also be nice.
Satyam
-
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