[syslinux] submenus and menu title
Ady
ady-sf at hotmail.com
Sat Sep 15 14:06:18 PDT 2012
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.
More information about the Syslinux
mailing list