[syslinux] Arrow key feature request

[Ady]

> On Thu, Sep 11, 2014 at 4:09 PM, Ady <ady-sf at hotmail.com> wrote:
> 
> >> Since keystrokes were brought up, this seems like a reasonable time to
> >> make the following seemingly simple-to-implement feature request:
> >>
> >> Navigating a multi-level menu structure seems to require use of
> >> UP/DOWN/ENTER/ESC. It would be easier to quickly search/navigate if it
> >> could be done with fingers stationed on the arrow keys so that the eyes
> >> can stay focused on the screen.
> >>
> >> Current (disliked-by-me) behavior:
> >>    LEFT ARROW: Jump to top menu entry (same as HOME and PAGE UP)
> >>    RIGHT ARROW: Jump to bottom menu entry (same as END and PAGE DOWN)
> >
> >
> > A minor correction. In a boot menu, [Home] and [End] move to the
> > respective first and last items. In a "short" (less than one screen)
> > menu, the [Page Up] and [Page Down] keys seem to obtain the same
> > result. But in a "larger" menu,  the [Page Up] and [Page Down] keys
> > will move the selection one page up/down, respectively.
> >
> >
> >> Preferred (requested) behavior:
> >>    LEFT ARROW: Return to previous menu (same as ESC on a submenu)
> >>    RIGHT ARROW: Enter submenu (or no action if not on a submenu entry)
> 
> > Considering that there is no "new" proposed action, breaking the
> > current behavior would be questionable for users that are already
> > taking advantage of it.
> 
> > I am not against changing behaviors (sometimes, it is worth), but
> > IMHO breaking a current behavior has to bring a very _clear_ gain,
> > while such change should be as less traumatic as possible for current
> > users.
> 
> In my opinion, this would be better addressed with a conditional
> directive than an outright change in current behavior.  Since it only
> affects (vesa)menu.c32, it should begin with "MENU ", perhaps "MENU
> ARROWKEY" (perhaps someone will think of another alternate behavior in
> the future).  It should also accept 1 optional parameter to turn it on
> or off.  When not present, it should turn the new behavior on.
> 
> -- 
> -Gene
 
 
What exactly do you mean with "When not present, it should turn the 
new behavior on"?

I think that the default behavior should be to keep the old (current) 
action, and change something (e.g. the action triggered by some arrow 
key) when a specific directive is added. In other words, do not break 
the traditional behavior unless the user explicitly says so.

Additionally, if changing the response to certain keystrokes is to be 
evaluated according to directives, then IMHO the name and arguments 
to such directive(s) should be clear, specific and expandable.

Now it is about one or two specific keys, tomorrow someone 
wants/needs/prefers changing additional key's behavior. Although more 
complex than a simple yes/no (or 0/1) condition, a more consistent 
(expandable) syntax could be:

 MENU <some_appropriate_name> 'key_stroke_or_combination' 'behavior' 

The 'behavior' could be, for example, 'ENTER', or a 'LABEL' (which in 
turn could be, for example, a 'MENU GOTO' directive). This syntax is 
similar to the 'MENU HIDDENKEY' directive.

BTW, the 'MENU HIDDENKEY' directive is another way to define actions 
when pressing specific keys (or combination of keys). Add the 'MENU 
IMMEDIATE' directive too.

Personally, I would very much like to see the known bugs and 
regressions (which are still keeping me on 4.xx) solved before adding 
new features, but that's just me. _Any_ contribution is welcome.

Regards,
Ady.