[syslinux] submenus and menu title

[Ady]

Date sent:	Sat, 15 Sep 2012 08:45:26 +0200
From:	Geert Stappers <stappers at stappers.nl>
To:	syslinux at zytor.com
Subject:	Re: [syslinux] submenus and menu title

> On Sat, Sep 15, 2012 at 03:40:07AM +0200, Ady Ady wrote:
> > Date: Fri, 14 Sep 2012 20:32:43 -0400
> > From: gene.cumm at gmail.com
> > > On Mon, Aug 6, 2012 at 7:33 AM, Gene Cumm <gene.cumm at gmail.com> wrote:
> > > > I can not speak for the intentions of the authors/contributors but
> > > > this may be a documentation bug rather than an implementation bug.
> > > >
> > > > "When the tagname is set, The submenu's title shall be the tagname
> > > > unless explicitly overridden inside the submenu."
> > > >
> > > > "The entry for the submenu is displayed as the effective menu title."
> > > > This one will certainly need minor verification.
> > > >
> > > > The addition of these two statements (assuming this was the
> > > > implementation intention) would correct the documentation bug.
> > > 
> > > HPA, is this documentation alteration the proper intention OR should
> > > the menu system be corrected, including a change such that the
> > > tagname, if set, is always shown in the parent and probably an
> > > additional directive 'MENU INHERITTITLE' to state that the tagname
> > > should be shown on the parent and the title of the child should be the
> > > same as the parent. OR should the tagname not affect the child's
> > > title?
> > > 
> >  
> > I have uploaded a simple graph, which shows the current situation, and what
> >  should be happening.
> 
> Now attached to this E-mail.
> 
 
I thought attachments were not allowed. Are they?
 
> > There is a "mix" between different directives:
> > "tagname", "label", "menu label" and "menu title".
> >  
> > and if there is something not clear enough, please don't hesitate to ask.
> >  
> 
> Please clarify 'SHOULD BE' from the last column.
> State clearly why it should be that way. 
> 
> Or rephrase 'SHOULD BE' in "what is expected but isn't"
> 
> Make an extra row that has in colomns value 'work needed' or just empty.
> 
> 
> Groeten
> Geert Stappers
> -- 

"A picture (or a table) means more than a 1000 words".

The "should be" and "current 4.05" are not a columns, but rows, 
indicating (by comparison) the difference between what should happen 
(according to the documentation) and what is currently happening in 
v.4.05 for each characteristic (the parent menu entry for the 
submenu, and the submenu title) in each case (8 cases being shown in 
the table).

There are 3 cells marked as "(to) review", and 2 cells marked as 
"must (be) change(d)". I'll skip the first 3, as I think that they 
still make sense and the criteria used for them is acceptable (yet, 
it is not documented). Moreover, those 3 cells (ie. fallback 
behavior) are already being used in some popular live CDs. So lets 
concentrate on the 2 cells that "must be changed" (in the 5th column 
of the picture, the 4th column of presented cases).

I'll take as example case #8 (last one). To build a submenu in a cfg 
file for this case, "tagname" is not used in "menu begin", there is 
no "menu label" nor "menu title" directives under "menu begin", but 
there is a "menu title" in the main menu (that's the meaning of the 
"0", "0", "0" for this case).

This is case #8:
 UI menu.c32
 MENU TITLE Main Parent Title
 
 MENU BEGIN
 # [no "t a g n a m e" for this "m e n u  b e g i n "]
 # [no "m e n u  l a b e l" for this "m e n u  b e g i n "]
 # [no "m e n u  t i t l e" for this "m e n u  b e g i n "]
 
 # [whatever in the submenu goes here]
 
 MENU END
 
 
Using such cfg file, the menu entry for the submenu in the parent 
menu is "blank", because there is no "tagname", no "menu label" and 
no "menu title". The entry in the parent menu can be selected, but 
there is no text being displayed in the parent menu for that entry. 
Here, the current behavior and the documentation are the same, so we 
are OK.

Now, still using the same case, we select the submenu entry in the 
parent menu (the one we just said has no text in the parent menu but 
that it is still selectable), and press "enter". The resulting menu 
title for the submenu being shown is "blank" (no menu title being 
displayed). This behavior is wrong. According to the documentation, 
since there are no "tagname", no "menu label" and no "menu title" 
inside the submenu, the parent menu title should be displayed in the 
submenu (supposedly "inherited"). This is what "should" be happening.

If the user wants to display the same menu title in the parent menu 
and in the submenu, he currently needs to explicitly repeat the menu 
title directive inside each submenu. The parent menu tile is NEVER 
inherited. From the 8 cases presented, no case shows the menu title 
being inherited (unless, of course, the directive is explicitly 
repeated).

This is, for example, case #1 from the table:
 UI menu.c32
 MENU TITLE Main Parent Title
 
 MENU BEGIN mytag
 MENU LABEL mysubmenu
 MENU TITLE my submenu title
 # [or the sub- "m e n u  t i t l e"
 # for this "m e n u  b e g i n "]
 # might be the same as the
 # main parent "m e n u  t i t l e"]
 
 # [whatever in the submenu goes here]
 
 MENU END
 
 
>From the table, case #4 is just as case #8, but "tagname" is being 
used in "menu begin".

Those 2 cases (8th and 4th from the table) "should" be corrected. Not 
only because of the documentation, but because the current behavior 
for those cases is not useful.

Hopefully, this long explanation helps to clarify the table.

TIA,
Ady.