Remove access key for Repeat button

Bug #688695 reported by Vish
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Banshee
New
Medium
banshee (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Binary package hint: banshee

Banshee provides an access key for the Repeat button, toolbar button, [it's a statusbar with button, so kinda acts like a toolbar button]
Pressing "Alt" underlines the access keys in the Repeat button. Access keys should *not* be provided for toolbar buttons.

From HIG <http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en#choosing-access-keys> :
"Give all labelled components an access key (underlined letter), with the exception of toolbar controls which would use up too many access key combinations."

It's not a regular menu either, so access is not in a consistent way.

Pressing the "Alt" keys should not highlight the Repeat options in the button.

Vish (vish)
Changed in banshee (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in hundredpapercuts:
assignee: nobody → Papercuts Ninja (papercuts-ninja)
importance: Undecided → Low
milestone: none → nt1-music
status: New → Triaged
Changed in banshee (Ubuntu):
assignee: nobody → William Friesen (william-friesen)
status: Triaged → In Progress
Changed in hundredpapercuts:
assignee: Papercuts Ninja (papercuts-ninja) → William Friesen (william-friesen)
status: Triaged → In Progress
Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 688695] [NEW] Remove access key for Repeat button

On Saturday 11,December,2010 03:19 AM, Vish wrote:
> Public bug reported:
>
> Binary package hint: banshee
>
> Banshee provides an access key for the Repeat button, toolbar button, [it's a
> statusbar with button, so kinda acts like a toolbar button] Pressing "Alt"
> underlines the access keys in the Repeat button. Access keys should *not* be
> provided for toolbar buttons.
>
>> From HIG
>> <http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en#choosing-access-keys>
>> :
> "Give all labelled components an access key (underlined letter), with the
> exception of toolbar controls which would use up too many access key
> combinations."

I actually interpret this as "It isn't mandatory to add an access key for
toolbar controls as they use up too many access key combinations," rather than
"Toolbar controls must not have access keys"

> It's not a regular menu either, so access is not in a consistent way.
>
> Pressing the "Alt" keys should not highlight the Repeat options in the
> button.

There's an important difference between the Repeat button and a normal toolbar
button. The repeat button is primarily text. A toolbar button is primarily an icon.

Rather than using "A" and "E" for repeat all/single, or whatnot, how about using
"R" as an access key to open up that menu?

--
Kind regards,
Loong Jin

Revision history for this message
Vish (vish) wrote :

> There's an important difference between the Repeat button and a normal toolbar
> button. The repeat button is primarily text. A toolbar button is primarily an icon.
>
It basically behaves like a combobox. And comboboxes on toolbars dont have access keys either.
I'm not sure why the combobox is not used instead. Maybe we can file a separate bug about switching to a combobox. Banshee has some weird non-GNOME UI in several places.

> Rather than using "A" and "E" for repeat all/single, or whatnot, how about using
> "R" as an access key to open up that menu?
>
That would work if only if the button was :
- Repeat
 -- Repeat All
 -- Repeat SIngle
 -- Repeat Off

Which would be making it a menu.

Changed in banshee:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

Thanks a lot for reporting this, however since Banshee is due to be dropped from the default installation, this bug no longer constitutes a papercut.

More information on what constitutes a papercut may be found here https://wiki.ubuntu.com/PaperCut

Changed in hundredpapercuts:
status: In Progress → Invalid
milestone: nt1-music → none
Revision history for this message
Chow Loong Jin (hyperair) wrote : Decision regarding Banshee vs Rhythmbox as default for Precise is not final

  affects hundredpapercuts
  status new

The discussion regarding Banshee is still ongoing and a decision has not been
made yet. Please wait a while longer before closing all these bugs.

--
Kind regards,
Loong Jin

Changed in hundredpapercuts:
status: Invalid → New
Changed in hundredpapercuts:
assignee: William Friesen (william-friesen) → nobody
Changed in banshee (Ubuntu):
assignee: William Friesen (william-friesen) → nobody
Changed in banshee (Ubuntu):
status: In Progress → Confirmed
Changed in hundredpapercuts:
status: New → Triaged
assignee: nobody → Timothy Arceri (t-fridey)
Changed in hundredpapercuts:
assignee: Timothy Arceri (t-fridey) → nobody
Revision history for this message
Timothy Arceri (t-fridey) wrote :

If anyone is interested in working on this bug I have detailed what I think needs to be done in the code in the upstream bug report comment 9: https://bugzilla.gnome.org/show_bug.cgi?id=619746#c9

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

Thanks a lot for reporting this, however since Banshee is due to be dropped from the default installation, this bug no longer constitutes a papercut.

More information on what constitutes a papercut may be found here https://wiki.ubuntu.com/PaperCut

Changed in hundredpapercuts:
status: Triaged → Invalid
no longer affects: hundredpapercuts
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.