Rhythmbox/Banshee will not minimize to sound-indicator if music is not playing

Likewise; I have the exact same problem.

This is apparently intentional. See bug #526552 about compliance with the sound menu specification. The specification itself ( https://wiki.ubuntu.com/SoundMenu#Music%20player%20section ) says:

"A compliant player should also keep playing if you close its window while it is playing; exit if you close its window while it is not playing; and remember exact state across sessions, so that after exit and relaunch it is as if the player had never exited."

The big problem is that the specification only really makes sense if the third part (exact preservation of state) also works, and Rhythmbox doesn't do that. That makes the behaviour of "close" rather inconsistent: if you invoke close while playing, the player will be hidden and can be restored with the same state if you restore it from the sound menu, but if you invoke close while not playing, state will be lost.

I think this is a major inconvenience. Think of the following scenario:

1. I have music playing in Rhythmbox and the Rhythmbox window is visible. Say, I have a particular artist selected in the Rhythmbox browser and am playing on shuffle, essentially meaning that I'm playing random tracks from that artist. This means the UI state is also important, not just the playback state.
2. I get a link to a YouTube video with music (or whatever) and decide to watch it, so I pause the music in Rhythmbox and hit Ctrl+W to get Rhythmbox out of my way in order to watch the video. Rhythmbox quits instead of hiding.
3. After watching the video I want to resume playback where I left off. The state is lost (including the track I was playing *and* UI state, e.g. having the artist selected in the Rhythmbox browser).

This breaks the user's flow in some cases pretty seriously, partially because state is lost and in particular because the loss or preservation of state is inconsistent.

I suggest that either Rhythmbox in Maverick should be modified to support exact preservation of state (including UI state) across sessions pretty quickly, or the change of making Rhythmbox quit on close should be reverted until exact preservation of state can be made to work.

Oh, god, I knew this would be intentional.

How about we close our chat client when we're not chatting with someone?

Mika Wahlroos Rhythmbox doesn`t quit if it`s not playing if you make the status icon to own the main window but the icon appears in the notification area applet . So i think it`s not intentional it`s maybe they didn`t care having "two music player icons" in the panel or they never thought hiding rhythmbox is important. A fix could be to modify the status icon plugin in such a way that the status icon can own the main window and be hidden , but this will brake the option for the mouse weal to change song because you can`t change from the sound icon , so that could also go.

Valentin,

I already have the status icon set to own the main window, so that doesn't appear to work for me as a workaround.

To me, both the bug and specification to which I linked appear to pretty clearly indicate that the behaviour of quitting when not playing is an intentional change. I simply argue that the change is not a good one until the rest of the specification (namely, preservation of state) is also fully working.

Mika i`m sorry ... i`m using dockbarx and with it if i don`t have the rhythmbox icon in the sys tray it wont hide. i just tested with the window list applet and with that it hides to the sound indicator , but only when playing . But the window list is ugly and default i want to customize my machine as I want it and it seems things get harder with each release .

I would like to contest the sanity of this behavior. What about those that have extremely large libraries that are set to be scanned upon RB's startup?

Every time I want to navigate my player my computer has to rescan hard drives of music.

So how do we disable this retarded behavior?

The behaviour is the one specified in https://wiki.ubuntu.com/SoundMenu#compliance, not a bug

Then change the specification. It is absurd and needs fixing.

I agree with unimatrix, it is an absurd spec. because it is very impractical. Can we file bugs against specifications? If this bug is strictly invalid, then I feel that that is what must be done.

Sebastien,

I'd like to point out that, as I said in comment #3, even if we sidestep the question regarding the sanity of the specification itself, it's definitely a bug that the Rhythmbox package in Ubuntu currently implements the specification only partially, leading to inconsistent behaviour. The package does implement the part about exiting if the window is closed while not playing, but does not implement the part about maintaining state across sessions. I'm inclined to believe that the latter part was added to the specification exactly because it would otherwise severely disrupt the consistency of behaviour and the user's flow. See comment #3 for a real-world scenario; I can give more if you're not convinced.

I argue that, as far as any single application goes, the specification should only be implemented either fully or not at all. This particularly applies to a high-prevalence application such as Rhythmbox. If you consider this particular one not to be a bug, should we instead open a new one for the Rhythmbox in Ubuntu not implementing the specification fully?

In relation to that, what's your understanding of how this inconsistency is going to be solved in the future? Is it just going to go away by itself in a future transition to Gnome 3? Or is the specification going to be fully implemented by Rhythmbox in Natty, thus perhaps making the behaviour consistent? Is that a realistic goal, seeing that Rhythmbox itself does little or nothing to implement full preservation of state?

@all :
Sebastien is not the person incharge of writing those specs, so, addressing your frustration towards him or on this bug report might not help getting this bug fixed.
To fix this bug the specs need to be changed. -> To change the specs, the best way is to bring up the discussion on the Ayatana mailing list. (Thats where the designers incharge of the specs are subscribed and can respond.)

Banshee is now following this behavior in natty. Updating the bug.

I will comment on Ayatana.

stop reopening this bug that's not one, feel free to comment the design on the design list though

Shouldn't it at least be set to 'opinion'?

if that can stop comments at the wrong place sure let's try!