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
> 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. > > -- > -GeneWhat 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.
On Sat, Sep 13, 2014 at 11:34 AM, Ady <ady-sf at hotmail.com> wrote:> >> 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"?When the _parameter_ is not present. -- -Gene