unity-design team mailing list archive

[Jan Claeys <lists@xxxxxxx>]

Op vrijdag 21-05-2010 om 08:26 uur [tijdzone +0200], schreef Philipp
Wendler:
> Am 20.05.2010 23:48, schrieb Jan Claeys:
> > Op donderdag 20-05-2010 om 12:00 uur [tijdzone +0100], schreef Mark
> > Shuttleworth:
> >> We discussed auto-attenuating music when a *phone call* comes through,
> >> which makes sense. But multiple music players.... that's up to the user
> >> to handle.
> >
> > Can anybody give a use-case for having 2 music players *playing* at the
> > same time?  And I'm thinking about playing music from a music library or
> > listening to on-line radio or similar, not another sound-producing
> > application...
> 
> I often use this.
> One example is when looking through a folder of video files to find the 
> correct one or to sort them. I have rhythmbox in the background playing 
> my favourite music and I open each of the video files in vlc, and I 
> would be upset if rhythmbox stopped playing every time.

Totem or VLC (or whatever you use) aren't music players taht should go
into the sound-menu IMO; they are okay to quickly check out the
occasional music file, but they are useless for listening to music in
the background.

Playing music is a background-task, looking at those video files (or
audio files, for that matter) is a foreground task and thus shouldn't go
into or influence the sound indicator menu.

> Ok, that's not exactly "playing music from a music library or listening 
> to on-line radio", but where would you draw the line? I would expect 
> that if playing music is a reason to pause the first player, playing a 
> video player would be, too.

No, see foreground vs. background above.  Or as other people call it: a
task/application vs. a service.

> I wouldn't even be sure if the browser shouldn't be considered a player 
> in this case, too. I guess a lot of people today use online sites 
> (Youtube etc.) as their primary source of audio and video, so they would 
> wonder why this is different from playing local media. But if you add 
> the browser, every silly website with audio would make your player stop, 
> because you cannot tell whether the user wanted this website to play 
> sounds or not.

Browsers are a problem, as there is no way for them to indicate the
intention (and if websites would be given a way to indicate their
intention, it would be abused by spammers from day one).  I suppose the
best solution is to have dedicated programs for streaming music that's
supposed to be running in the background (this could be based on prism
or similar for a quick solution!).

> As someone else on the thread said:
> If you keep it like it is, every user will understand the situation, and 
> will know what he needs to do if it disturbs him. After all, this is 
> nothing different from having a radio and a cd player playing in the 
> same room.

> But if you do automatically disable audio applications, users will be 
> surprised because something happened (first player stops) that they 
> didn't initiate, and probably many users wouldn't notice why this 
> happened. You would need to add controls to disable this behaviour for 
> now, and globally.
> 
> So I'm strongly against this.

As outlined above: this would *NOT* influence all audio-producing
applications, only those that register themselves as background tasks,
or services, or whatever you want to call them.

I'm pretty sure there would be problems in the beginning when
implementing something like this.  E.g. programs implementing both
paradigms might have some work to implement the difference in their
code.

But it could become very convenient once we get things right...



-- 
Jan Claeys