Re: non-visible options vs menuconfigs

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 3211 bytes --]

On Monday 22 April 2013 16:26:49 Yann E. MORIN wrote:
> On Mon, Apr 22, 2013 at 02:19:50PM -0400, Mike Frysinger wrote:
> > On Monday 22 April 2013 14:00:46 Yann E. MORIN wrote:
> > > As far as I remember, this has always been the behaviour of menuconfig.
> > > 
> > > What do you suggest the frontends do in this case, short of re-ordering
> > > the options (which I think is not correct) ?
> > 
> > i think you missed a critical part of my proposal:
> > 	seems like *if a node is unprintable*, it should get skipped for
> > 	menuconfig purposes
> 
> Ah, yes, I missed it. And it is part of the solutions I exposed, too:
> 
>     On the other hand, we could consider dependent options as candidates
> for being sub-options until we see the first non-dependent option with a
> prompt.
> 
> > to modify your example, i'm proposing a change for:
> > 	menuconfig MENU_A
> > 		bool "A"
> > 	
> > 	config OPT_B
> > 		bool
> > 	
> > 	config OPT_C
> > 		bool "C"
> > 		depends on MENU_A
> > 
> > OPT_B is not shown to the user (there is no option text), therefore it
> > should automatically get skipped when searching for options to collapse
> > into the menuconfig MENU_A.
> > 
> > i do agree that if OPT_B had text, then the existing behavior would be
> > unchanged.
> 
> And as I pointed out, this would break as soon as an option with a prompt
> (which you call 'option text') is added in-between. For example, starting
> with:

sure.  i'm focusing on the non-displayed case since it wouldn't be a 
behavioral change, and because that's the only reason that EXPERT broke.  
there aren't EXPERT & non-EXPERT options there (at least, unintentional).  i 
don't think we should worry about this case because, as you pointed out, we 
already have kconfig language to enforce the behavior if truly desired.

using the EXPERT case as an example, i don't think we want the re-ordering as 
this is a general knob.  we've got specific items which make more sense when 
grouped elsewhere, and we've got a "dumping bucket" which the current EXPERT 
menuconfig is designed to hold.

for example, checkpoint/restore makes more sense when grouped with 
cgroups/namespace (and it actually appears *before* the EXPERT menuconfig, so 
you'd have to build the entire tree first before doing possible re-
ordering/processing).

another example, the vmcounters/slub debug better fits with the non-expert 
memory settings (like "choose your allocator").

> This would change the semantic of the language anyway, where currently
> your example disrupts the dependendcy chain. Granted, it looks like a
> good change, but I think we should not encourage people to be lazy, and
> we better want them to be careful about what they intend to do, about
> what they review and ack (myself largely included! :-] ).

sure, but i think we can segment this.  i don't think we should hassle 
developers with details that make 0 difference to the end result.  that's why i 
think automatically handling options that don't get displayed is OK.  but 
resorting options and possible sticking them in different menus than what the 
source Kconfig files declare violates KISS.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]