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
Gene Cumm <gene.cumm at gmail.com> writes:> 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.I just saw this and thought I should kibitz. How about have a way to explicitly map keys to behaviors and just default the keys to their current behavior. The implementation would be an extra table lookup (no matter the mapping) it gives power to accomodate everyone's peculiarites and it should be very little additional code compared to today. (Mostly the change would be parsing the configuration directives). You can later get into grand fights over what the best default behavior is but having it configurable will at allow room for people to disagree. Eric
On 09/22/2014 07:03 PM, Eric W. Biederman wrote:>>> >>> What exactly do you mean with "When not present, it should turn the >>> new behavior on"? >> >> When the _parameter_ is not present. > > I just saw this and thought I should kibitz. > > How about have a way to explicitly map keys to behaviors and just > default the keys to their current behavior. > > The implementation would be an extra table lookup (no matter the > mapping) it gives power to accomodate everyone's peculiarites > and it should be very little additional code compared to today. > (Mostly the change would be parsing the configuration directives). > > You can later get into grand fights over what the best default > behavior is but having it configurable will at allow room for > people to disagree. >Would be easy enough to implement, something equivalent to MENU COLOR. So if someone wants a project... -hpa