[syslinux] Menu system bug - MENU DEFAULT not working

[Ady]

Date sent:      	Thu, 11 Oct 2012 19:12:50 +0200
Subject:        	Re: [syslinux] Menu system bug - MENU DEFAULT not 
working

> The patches sent by Matt (for readconfig.c and menumain.c) indeed
> resolve my issue! After applying, the menu system behaves exactly as
> one would expect. Thank you.
> 
> In my opinion, applying those two patches should be called BUGFIX and
> what it does is exactly that - if an user uses MENU DEFAULT then he
> wants the particular entry to be _default_ when entering the menu! The
> existing behavior, where the submenu goes back to previously selected
> entry instead of switching to DEFAULT value is _in my opinion_ wrong
> and NOT EXPECTED.
> 
> I vote for those patches to be applied to official syslinux releases.
> If user wants submenu to start on any different menu then MENU
> DEFAULT, then he should not use MENU DEFAULT ... that's it
> 
> Thank you
> 
> Tomas M
> slax.org
> 

Hi Tomas,

Quoting Matt:

> >
> > Well, the patch I posted today breaks the existing behaviour for any
> > default entry in a submenu, not just the MENU GOTO directive.

I kept thinking about SUBmenus, even after Matt's comment that his 
patch would affect not just MENU GOTO but all MENU DEFAULT behavior 
regarding SUBmenus.

But then I started to think about the PARENT menu behavior. When 
going back from a submenu to its parent menu using [ESC], the current 
behavior (as of 4.06pre12) is already expected by users. To be 
consistent, the behavior going up to the parent menu shouldn't be 
changed.

I don't have the knowledge to test the patch alone, so I'll have to 
wait for another prerelease so to confirm if this is the case or not.

I know of LiveCDs that use submenus (either with MENU BEGIN or with 
MENU INCLUDE), and users are used to "navigate" through the submenus 
up and down. If a user is already in the middle of the list of 
entries, goes down to a submenu and goes back "up" to the parent menu 
again by using [ESC], such user already expects to find the same 
selected entry as before. To find selected a different entry in the 
parent menu would be very "unfriendly" in such situation.

Ideally, MENU GOTO (and MENU EXIT [TAGNAME]) combined with submenus 
should work correctly, but the current behavior when going back "up" 
to a PARENT menu should be also maintained.

This means Consistency for:
_ MENU DEFAULT (expecting always the same behavior / result),
 but also for:
_ navigating through menus as in previous versions, as the user 
already expects.

As I said, I'll have to wait for a prerelease to test it, but maybe 
the best solution is really:

> > Alternatively, we could invent a new MENU directive that means "Forget
> > the last selected entry if we leave this submenu".

I am thinking (out loud) about something like:

   _ MENU DEFAULTONCE ("defaultonce" altogether; the same behavior as 
the "old menu default")
   _ MENU DEFAULTALWAYS ("defaultalways" altogether; the behavior is 
"always select this entry as menu default")

OR, a different alternative:
   _ MENU DEFAULT [option]

where if [option] is not present, then behave as the "old menu 
default", and if [option] is 0 (the number zero), then "_always_ 
select this entry as menu default".

The only problem with that last alternative is that I have already 
seen "BAD" directives in cfg files in the form of
    "MENU DEFAULT my_default_label"
just because the author of the cfg file is misunderstanding how the 
directive is used.

Apologies for the rant. I guess I'll be wiser after testing a 
prerelease.

Regards,
Ady.