[syslinux] submenus and menu title

[Ady]

Date sent:	Sat, 15 Sep 2012 14:07:04 -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>

> To start over:
> 
> 1) Attached image is of the top menu from the attached config file.
> 2) Use of "LABEL", "MENU LABEL" or "LABEL"; "MENU LABEL" to pre-label
> a submenu generates visual errors.  Results from these 12 attempts
> should be ignored but are included in the end config/image for
> completeness.
> 3) Further statements of this email (not necessarily thread) shall
> only discuss the remaining valid cases (4).
> 
> Observed behavior is that the tagname is never used for the title of
> the submenu, the "MENU TITLE" of the submenu overrides the tagname for
> display in the parent menu and the submenu does not have a title
> unless explicitly set.
> 
> The inheritance clause in the docs would lead one to expect the title
> of a submenu to be inherited from the parent unless overriden however
> no title is observed (conflict).  I feel it would be better to have
> this behavior documented and a new directive "MENU TITLEAPPEND" (or
> the like) added.  Having a submenu inherit the title as-is could lead
> to confusion in the context of what menu a user is actually observing.
>  The effect of using "MENU GOTO" must also be considered to prevent
> overly long titles/
> 
> When a submenu has a "MENU TITLE" directive, the tagname is solely
> used for jumping via "MENU GOTO".  It does, in this context, make
> sense that the submenu item string comes from the submenu's "MENU
> TITLE".  It may be beneficial to have a new directive to override this
> to the effect of "MENU PARENTLABEL Label In Parent Menu".
> 
> Ady, would you concur with these observations?
> 
> How do you feel about my assessments and opinions?
> 
> -- 
> -Gene
> 

Hello Gene,

Your first observations are in line with my table (which was built 
from many tests, including intentional "bad" cases).

But I don't think additional directives are really necessary (at 
least not for the purpose of solving the inheritance of the parent 
menu title when it is desired by the user).

When explicit directives are included, there is no question; all 
works. When part of the relevant directives are not explicitly 
included in the cfg file, there are "fallback" rules so the resulting 

menu is displayed following such rules.

Currently, in v.4.05, here are the fallback rules (the current 
behavior) for two different characteristics of the resulting menu.

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. 
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.

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,
  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:
  
  2.C'._ The parent "MENU TITLE" is inherited and displayed as 
submenu title. If it is not explicitly used, then,
  2.D'._ No submenu title is displayed.

Note that the "tagname" is not part of the fallback rules for the 
sub- menu title, and that's OK. Not using "tagname" for the sub- menu 
title maintains the current behavior (as it is already used in live 
CDs). But, using "tagname" could potentially also be part of the 
fallback rules for submenu title. You just need to be sure it doesn't 
change the current rules that have higher priority.

The only (2) cases that are affected by the suggested change are the 
ones where "menu label" and "menu title" are not explicitly used 
inside the submenu (whether "tagname" may be used or not): currently, 
no sub- menu title is being displayed at all. These respectively 
correspond to my "case #4" and "case #8" in my table. Instead of not 
displaying any submenu title at all, display the parent menu title as 
submenu title (inherit it).

If the tagname is also considered as fallback rule for the displayed 
submenu title, then the changing rules would result in:

  2.C''._ The "TAGNAME" is displayed as submenu title. If it is not 
explicitly used, then,
  2.D''._ The parent "MENU TITLE" is inherited and displayed as 
submenu title. If it is not explicitly used, then,
  2.E''._ No submenu title is displayed.

Again, you just need to be sure it doesn't change the current rules 
that have higher priority, "2.A._" and "2.B._".

So, I am not suggesting to add more directives (unless you think more 
functionality or possibilities are desired or needed). I am 
suggesting to correct the fallback rule "#2.C._" so to make it as my 
suggested "2.C'._" and "2.D'._" (or, alternatively, as 
2.C''/D''/E''._ suggested rules).

Am I making sense?

TIA,
Ady.