[syslinux] submenus and menu title

[Gene Cumm]

On Sep 15, 2012 5:42 PM, "Ady" <ady-sf at hotmail.com> wrote:
> From: Gene Cumm <gene.cumm at gmail.com>
>
> > 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.

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.

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

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

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

--
-Gene