From: Dirk Gouders <dirk@gouders.net>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: linux-kbuild@vger.kernel.org
Subject: Re: [RFC] mconf: suppress empty submenus
Date: Fri, 17 May 2013 06:22:45 +0200 [thread overview]
Message-ID: <ghip2ikzfu.fsf@mx10.gouders.net> (raw)
In-Reply-To: <20130516230404.GB19534@free.fr> (Yann E. MORIN's message of "Fri, 17 May 2013 01:04:04 +0200")
"Yann E. MORIN" <yann.morin.1998@free.fr> writes:
> Dirk, All,
>
> On 2013-05-15 16:05 +0200, Dirk Gouders spake thusly:
>> I noticed that sometimes it happens that there are empty
>> submenus, and I tried to see if they can't be suppressed
>> by mconf (if not explicitely done by the kbuild-language).
>
> I think we still want submenus to be visible if they are not hidden by
> any condition in the Kconfig. If the developper did not explicitly add
> masking condition, we should *not* try to mask it from the frontends.
>
> However, I agree that entering an empty menu can just be deceptive. If
> we could find a way to render an empty menu, and prevent the user from
> entering it, then that would be a huge win, I think.
>
> For example, menus are rendered as thus for now:
>
> This is a submenu --->
>
> What about representing empty submenus as thus:
>
> This is a submenu ----
>
> Also, we have menuconfig which are simply empty if not selected, but can
> anyway be entererd like any other submenu:
>
> [ ] menuconfig entry --->
> (Always empty when entered if not selected)
>
> which could be similarly rendered as:
>
> [ ] menuconfig entry ----
>
> This one is really deceptive, and should be handled in the same scheme
> as well.
Hello Yann,
I like that scheme. Maybe ---- can become ---0 or similar for better
perceptibility, but I think what counts would be that the user knows
that we know that there are empty menus/menuconfigs and we are treating
them properly.
What I also like is that I think this scheme would justify a new
function "menu_is_empty()" and we do not need to change the current
behavior of "menu_is_visible()".
While playing with the empty menus, I noticed that there are some more
things that probably should be fixed and that I have on my list:
* mconf: Using Arrow-Keys should be handled properly (for empty menus)
(The point why I thought users get irritated by empty submenus)
* mconf: "Z" does not work in empty menus
* expr.c: Some days ago, there was a timeslot when "IRQ subsystem" had
just one config with a prompt in it and I tried to make the
visibility of the menu dependent on the same symbol as the
only one config option.
That did not work and I found out that this is because of the
expr_eliminate_dups* family of functions. I am still figuring out if
this is correct behavior or if I just misread the kconfig-language
documentation. The attached Kconfig that I use to trigger exactly that
point, also outputs an error because of an expression with an unknown
type when "Z" is pressed.
Dirk
------------------------------------------------------------------------
mainmenu "Kconfig Testing Configuration"
config MAY_TEST_VAR
def_bool y
config SRCARCH
string
prompt "srcarch"
option env="SRCARCH"
---help---
Helptext
menu "Testmenu"
visible if MAY_TEST_VAR
config TEST_VAR
bool "Test option" if MAY_TEST_VAR
---help---
Help for TEST_VAR
endmenu
next prev parent reply other threads:[~2013-05-17 4:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-15 14:05 [RFC] mconf: suppress empty submenus Dirk Gouders
2013-05-15 14:05 ` [PATCH] " Dirk Gouders
2013-05-16 8:24 ` [RFC] " Dirk Gouders
2013-05-16 23:04 ` Yann E. MORIN
2013-05-17 4:22 ` Dirk Gouders [this message]
2013-05-17 10:28 ` [RFC] mconf: mark empty menus/menuconfigs different form non-empty ones Dirk Gouders
2013-05-17 10:28 ` [PATCH] " Dirk Gouders
2013-05-17 12:42 ` [PATCH v2] mconf/nconf: mark empty menus/menuconfigs different from " Dirk Gouders
2013-05-19 15:14 ` Yann E. MORIN
2013-05-19 19:49 ` [PATCH v3] " Dirk Gouders
2013-05-20 15:50 ` Yann E. MORIN
2013-05-19 9:08 ` [RFC] mconf: mark empty menus/menuconfigs different form " Yann E. MORIN
2013-05-19 16:22 ` Dirk Gouders
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=ghip2ikzfu.fsf@mx10.gouders.net \
--to=dirk@gouders.net \
--cc=linux-kbuild@vger.kernel.org \
--cc=yann.morin.1998@free.fr \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox