[syslinux] submenus and menu title

[Gene Cumm]

On Sat, Sep 15, 2012 at 11:40 PM, Ady <ady-sf at hotmail.com> wrote:
> From:                   Gene Cumm <gene.cumm at gmail.com>
>> 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 see this.  This is a documentation bug that should state that the
"MENU LABEL" is allowed under a "MENU BEGIN" directive.  I would have
interpreted this as against syntax

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

I also see this.  This would be a code bug that "MENU LABEL" is (but
should not be) overriding "MENU TITLE" for the submenu's title.

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

Bad choice of words.  Both choices/alternatives to the decision.
There are valid points to enabling the inheritance as you point out.
There are valid points to maintaining the lack of inheritance as I'm
trying to point out.

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

But this untitled submenu would encourage you to explicitly place one
there to help your end users.

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

-- 
-Gene