GNOME Bugzilla – Bug 619746
[HIG] Banshee provides an access key for a toolbar button (was: Mnemonic conflict : Edit menu and Repeat single]
Last modified: 2020-03-17 08:53:59 UTC
Edit menu and Repeat single shares the same mnemonic 'e'
Another observation : Current steps for selecting 'Repeat All' . 1. Currently at 'Repeat Off' 2. To change to Repeat All: 'Alt + O' and 'A' 2. To change to Repeat Off: 'Alt + A' and 'O' Instead, a standard mnemonic for Repeat menu 'R', then mnemonics for All, Single and Off. So for Repeat All, it would be 'Alt + R' and 'A'
<vish> guys, this is not a bug , https://bugzilla.gnome.org/show_bug.cgi?id=619746 , if he is referring to Playback>Repeat> Repeat Singl_e and _Edit menu, that is not an issue .. is a top level menu and it is not necessary that it needs to not conflict with something else somewhere is some other menu.. HIG even allows repetitions of mnemonics /within/ the *same* menu <bugbot> Bug 619746: normal, Normal, 1.x, banshee-maint, UNCONFIRMED, Mnemonic conflict : Edit menu and Repeat single <vish> dnielsen , hyperair: ^ <vish> s/somewhere is/somewhere in* <hyperair> hmm? well i can't change bug statuses in bgo <vish> you can probably close that bug as NOT a BUG hyperair: you should get bugzillafu ;)
Created attachment 176176 [details] Screenshot with red lines marking mnemonics in conflict. (In reply to comment #2) > <vish> guys, this is not a bug , > https://bugzilla.gnome.org/show_bug.cgi?id=619746 , if he is referring to > Playback>Repeat> Repeat Singl_e and _Edit menu, No. Take a look at the screenshot. Its a conflict with _Edit menu and the bottom bar 'Repeat singl_e'. > that is not an issue .. is a > top level menu and it is not necessary that it needs to not conflict with > something else somewhere is some other menu.. > HIG even allows repetitions of > mnemonics /within/ the *same* menu Try this : 1. Click the bottom 'Repeat' button and change it to 'Repeat _All' 2. Ctrl+ A - it invokes Repeat the menu in the bottom bar. 3. Click the bottom 'Repeat' button and change it to 'Repeat singl_e' 4. Now try ctrl+e. 5. I'm expecting the same result as steps 1 and 2. > <bugbot> Bug 619746: normal, Normal, 1.x, banshee-maint, UNCONFIRMED, Mnemonic > conflict : Edit menu and Repeat single > <vish> dnielsen , hyperair: ^ > <vish> s/somewhere is/somewhere in* > <hyperair> hmm? > well i can't change bug statuses in bgo > <vish> you can probably close that bug as NOT a BUG > hyperair: you should get bugzillafu ;) Not changing the status of this bug. I'll leave that to you.
Thanks, The bug is a little clearer now. The initial bug was not clear. (In reply to comment #3) > Created an attachment (id=176176) [details] > Screenshot with red lines marking mnemonics in conflict. > > (In reply to comment #2) > > <vish> guys, this is not a bug , > > https://bugzilla.gnome.org/show_bug.cgi?id=619746 , if he is referring to > > Playback>Repeat> Repeat Singl_e and _Edit menu, > > No. Take a look at the screenshot. Its a conflict with _Edit menu and the > bottom bar 'Repeat singl_e'. > As I'v mentioned earlier, repetition is allowed. It's a fine balance in choosing the right access keys for *all* menu items. Quoting from <http://library.gnome.org/devel/hig-book/stable/menus.html.en> : "Provide an access key for every menu item. You may use the same access key on different menus in your application, but avoid duplicating access keys on the same menu." The bug here is, Banshee provides an access key for a toolbar button [yea, its a statusbar with button, so kinda acts like a toolbar] <http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en#choosing-access-keys> It's not a regular menu either, so access is not in a consistent manner. Access keys should *not* be provided for toolbar buttons. I'd suggest pressing the "Alt" keys not highlight the Repeat options in the button there. The bug needs to be re-titled/re-focused.
Re-opening, per above comment.
Created attachment 176231 [details] [review] Remove access keys for repeat button
Review of attachment 176231 [details] [review]: This patch removes the access keys from the Playback menu as well, no?
I don't think so. I am still able to, for example, Play/Pause with Alt+P, P
I have spent some time working on this bug (lots more than I planned) and thought I would share my results for anyone else who would like to have a go at finishing this one off. Gabriel is right the current patch removes the access keys from the Repeat submenu in the Playback menu. This is because they both share the same instance of PlaybackRepeatActions. Now I tried many ways of removing the underscores from the label when the RepeatActionButton calls CreateMenu() but I aways had to add them back in for PlaybackActions to use. However it seems that the GTK Menu object does not store its own copy of the label and so goes back to use the shared value in PlaybackRepeatActions so this technique will never work. So how do we solve this? My current thinking is we need to create two separate RepeatAction classes one for each menu. The common code between them should be moved into a base class which they both extend. Thats the easy part the hard part is they both need to be aware of each other so that when one radio repeat action is selected in one object the other object is updated to reflect the change (so that the selected repeat option in the menus are consistent). I've currently spent to much time on this bug and my mono/c# skills are not up to the task so hopefully this information can be used by someone else as a starting point. Good luck
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.