Music player should not show its main window if it launches when play button is pressed

Bug #752033 reported by Dylan McCall
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
The Sound Menu
Triaged
Low
Unassigned
indicator-sound (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: indicator-sound

When my music player is not running, the sound menu still keeps its music controls to keep things tidy. However, when I press the Play button, the player's main window opens! This is improper, because it is inconsistent with pressing Play or Pause from the menu when the player is already running and it is inconsistent with our presentation of the music player as a service. A user pressing this button should not expect the player's main window to appear.

Victor Vargas (kamus)
Changed in banshee (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Conor Curran (cjcurran)
Changed in banshee (Ubuntu):
status: Triaged → Invalid
Changed in indicator-sound:
importance: Undecided → Low
assignee: nobody → Conor Curran (cjcurran)
Revision history for this message
Conor Curran (cjcurran) wrote :

Hi Dylan,

Thats a valid point but the issue here is more todo with that fact that I literally fake a service like effect by starting the player and then once the player is up and going I send it a play command. Therefore I have no way to
when initialising the player tell it to begin in a hibernated state.

Mpt any thoughts here ?

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Good thinking, Dylan.

I agree it would be more consistent if the player could start playing without its window opening in this situation.

I guess that would require introducing, and evangelizing, some new API (or even something as simple as a standard command-line option?) for a player to start up hidden and playing.

Conor Curran (cjcurran)
Changed in indicator-sound:
status: New → Triaged
Conor Curran (cjcurran)
Changed in indicator-sound (Ubuntu):
status: New → Confirmed
Revision history for this message
Paul Hoell (hoellp) wrote :

This still happens more than one year later with Rhythmbox. A quick glance at the manpage of rhythmbox-client suggests, that the necessary behaviour could be possible with it.

If the maintainer(s) of indicator-sound agree, this could specify for a Papercut.

Revision history for this message
Xavier Claessens (zdra) wrote :

Here is how I think it should be implemented:
1) rhythmbox should use GApplication to implement a few GAction like "play".
2) rhythmbox should install a .service file to be dbus-activatable
3) rhythmbox should install a org.gnome.Rhythmbox.desktop file that tells the actions it implements. See http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
4) Unity can then start rhythmbox and play by invoking the "play" action on rhythmbox, using g_desktop_app_info_launch_action().

Most of the work should be done upstream IMHO.

Revision history for this message
Lars Karlitski (larsu) wrote :

Yeah, this is impossible in the current spec. It's definitely not a Papercut: while you can start rhythmbox-client headless, there's no way for media players to specify the command for their headless mode in the desktop file.

Changed in indicator-sound:
assignee: Conor Curran (cjcurran) → nobody
no longer affects: banshee (Ubuntu)
Revision history for this message
Lars Karlitski (larsu) wrote :

Xavier, I very much agree. We just need one additional thing in .desktop files: Implements.

Then we could have Implements=org.freedesktop.MediaPlayer, which entails having the actions you're suggestions (don't even need to be GActions, org.freedesktop.Application has an ActivateAction as well).

I'm planning to write this up at some point and suggest it on the next freedesktop summit.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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