[syslinux] submenus and menu title

[Ady]

Date sent:      	Sat, 15 Sep 2012 22:37:56 -0400
From:           	Gene Cumm <gene.cumm at gmail.com>
To:             	For discussion of Syslinux and tftp-hpa 
<syslinux at zytor.com>
Subject:        	Re: [syslinux] submenus and menu title
Send reply to:  	For discussion of Syslinux and tftp-hpa 
<syslinux at zytor.com>
	<mailto:syslinux-request at zytor.com?subject=unsubscribe>
	<mailto:syslinux-request at zytor.com?subject=subscribe>

> On Sep 15, 2012 5:42 PM, "Ady" <ady-sf at hotmail.com> wrote:
> >
> > The first characteristic is, in the parent menu, the menu entry that
> > represents the submenu.
> >
> > 1._ For the sub- menu entry in the parent menu:
> > 1.A._ "MENU LABEL" is displayed as menu entry in the parent menu.
> 
> No, please look again. You will notice a broken entries "ml-300",
> "ml-301", "ml-310" and "ml-311", which do nothing followed by the
> proper entry for the submenu to LABEL 300 and up. Your attempt at
> calling that the descriptor is incorrect unless you can provide me a
> proper test config and preferably also an image.
> 
> Please see the example for "MENU DISABLE" in doc/menu.txt if you want
> the proper way to do a pre-label.
> 

I'm sorry but I don't understand the relation to your "ml-3xx" 
examples, nor to the "MENU DISABLE" examples.

Here is a cfg file using the "1.A._" fallback rule (case#2):
 UI menu.c32
 MENU TITLE My Parent Title
 
 # case2
 MENU BEGIN case2tag
 MENU LABEL Mlabel2
 
 LABEL hello2
 COM32 hello.c32
 
 MENU END
 
When the MENU LABEL directive (in the example, "MENU LABEL Mlabel2") 
is used, the menu entry displayed in the parent menu would be such 
MENU LABEL (in the example, "Mlabel2").
 
I have more example cases, using additional directives, and all cases 
respect such MENU LABEL directive (when it exists) as menu entry in 
the parent menu.
 
> > If it is not explicitly used, then,
> > 1.B._ Sub- "MENU TITLE" (the one inside the submenu) is displayed
> > as menu entry in the parent menu. If it is not explicitly used, then,
> > 1.C._ The "TAGNAME" is displayed as menu entry in the parent menu.
> > If it is not explicitly used, then,
> > 1.D._ The sub- menu entry in the parent menu is selectable, but no
> > text is displayed to indicate that such entry exists.
> 
> Yes, I agree on these three points except that a ">" exists on the end
> of the line to indicate a submenu item.
> 
 
Yes, of course, the ">" symbol is always there.
 
> > That resumes the current behavior for the sub- menu entry in the
> > parent menu, for all relevant cases. I don't have a problem with such
> > behavior (and it is already being used in popular live CDs too),
> > except that it should be documented better.
> >
> > Now, the second characteristic of the resulting (sub)menu, is the
> > sub- menu title, which is currently behaving after the following
> > fallback rules.
> >
> > 2._ For the sub- menu title in the submenu:
> > 2.A._ Sub- "MENU TITLE" (the one inside the submenu) is displayed
> > as submenu title. If it is not explicitly used, then,
> > 2.B._ "MENU LABEL" is displayed as submenu title. If it is not
> > explicitly used, then,
> 
> 2B should not happen.  Please indicate which of my 16 examples
> displayed this as I did not observe this behavior.  If none of mine
> exhibit this behavior, please submit an appropriate config that does,
> preferably with an image.
> 
 
The example I just wrote in this same email, "case#2", is such an 
example, where the sub- menu title being displayed is in fact the 
MENU LABEL of the submenu ("Mlabel2" in the example), since the sub- 
MENU TITLE directive is not explicitly used in the submenu.
 Moreover, this fallback rule is already being used by popular live 
CDs, but the behavior is not documented.
 
> > 2.C._ No sub- menu title is displayed.
> >
> > That resumes the current behavior for the sub- menu title, for all
> > relevant cases. HERE WE HAVE THE PROBLEM.
> >
> > The first issue, which is very easy to correct, is that those
> > behaviors "#2.A._" and "#2.B._" are not explicitly documented (and
> > yet, both are already being used by popular live CDs).
> >
> > The second issue is that current fallback rule "#2.C._" "IS WRONG"
> > (well, at least not useful and it goes against the documentation).
> > The correction I am humbly suggesting, is to make it:
> 
> I agree it's against documentation.  However, I can easily see valid
> points for both decisions.  It would make it easier for a config
> author like yourself to have this behavior however an end-user now
> looses track of where they may be in a large, complex menu system and
> may not know where the top of the menu system is located.  The current
> behavior forces a config author to explicitly convey to their end user
> what a given submenu is for.
> 
 Please clarify what you mean with "both decisions". Which exact 
decisions are you referring to?
 My suggestion only replaces a "blank" subtitle with the inherited 
menu title (or, with the submenu tagname, for the second alternative 
suggestion, if you'd rather use that one). So, regarding the end user 
not knowing which submenu he is seeing on the screen, it is the same 
potential "confusion". He now ( v.4.05 ) sees no subtitle at all (in 
my case#4 and case#8 of my table), against using at least the parent 
menu title as subtitle too.

My suggestion would be the only case where the parent menu title is 
indeed inherited, while maintaining ALL the rest fallback rules with 
higher priority as they are now. Currently, it is never inherited, in 
no case.

TIA,
Ady.