Bug 1175431 - YaST Menu Bar in NCurses missing standard key handling
YaST Menu Bar in NCurses missing standard key handling
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
All Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/gAkzTDEv
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-08-18 09:10 UTC by Stefan Hundhammer
Modified: 2020-09-07 08:21 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Hundhammer 2020-08-18 09:10:19 UTC
The new MenuBar widget in libyui-ncurses is still missing some standard key handling that is present in all other menu systems:

- In a toplevel menu, [Return] and [Space] should 
  open the menu.

- In a submenu, [Backspace] should go one menu level up.

- The highlighted hotkeys only work with [Alt], not also as
  plain keys: When the "File" menu is open, [Alt][Q] triggers
  the "quit" action, just [Q] does not.


To discuss:

- When the "View" menu is open, [Alt][F] does not open
  the "File" menu.

  This might clash with the shortcut conflict resolver, 
  but IMHO users might still expect this to work.
Comment 1 Lukas Ocilka 2020-08-18 09:30:23 UTC
Stefan, it would be nice to have some feedback from Mageia guys first. How they
use their menu bar? How much is that compatible with the new "upstream"
solution? For some reason we have our own solution, so I guess we want to offer
them our one as a replacement.

I guess they also have some key handling there? Are there any more features
that they would really miss and can't switch?
Comment 2 Stefan Hundhammer 2020-08-18 09:53:40 UTC
I don't see a connection with this bug.

This bug is about standard behaviour; the way that other menu systems are handling keys, i.e. the way that users expect it to behave.
Comment 3 Lukas Ocilka 2020-08-18 12:01:04 UTC
It's the only bug (well a feature request) that wants to continue with the
implementation before we know how to continue in general. The connection is
simple: to get feedback before we decide how to invest our time.

The Mana implementation probably has some shortcut conflict in ncurses
https://github.com/manatools/libyui-mga/blob/master/screenshots/MenuBar-ncurses.png

And I don't see any shortcurts in Qt
https://github.com/manatools/libyui-mga/blob/master/screenshots/MenuBar-Qt.png

The same for GTK
https://github.com/manatools/libyui-mga/blob/master/screenshots/MenuBar-Gtk.png

(but they, e.g., do support icons [yes, unrelated] in graphical interface)
Comment 4 José Iván López González 2020-09-07 08:21:02 UTC
(In reply to Stefan Hundhammer from comment #0)
> The new MenuBar widget in libyui-ncurses is still missing some standard key
> handling that is present in all other menu systems:
> 
> - In a toplevel menu, [Return] and [Space] should 
>   open the menu.
> 
> - In a submenu, [Backspace] should go one menu level up.

Is this actually standard? I am playing with some apps (Firefox, Thunderbird, some gtk apps) and backspace does nothing. 

> 
> - The highlighted hotkeys only work with [Alt], not also as
>   plain keys: When the "File" menu is open, [Alt][Q] triggers
>   the "quit" action, just [Q] does not.

In fact, it seems that the standard way to work is with plain keys. In all cases I have played with, the options list of a menu only reacts to a plain key (without alt). This solves the conflict with other hotkeys. For top level menus, we use (alt + hotkey), and once a menu is open, we use plain key. So we could jump to another top level menu with alt + hotkey without conflicting with any shortcut of the current menu list.

BTW, in gnome shell is challenging to find an app with a classical menu bar. 

> 
> 
> To discuss:
> 
> - When the "View" menu is open, [Alt][F] does not open
>   the "File" menu.
> 
>   This might clash with the shortcut conflict resolver, 
>   but IMHO users might still expect this to work.