Re: [Ayatana] Two suggested designs for the Sound Indicator

[Philipp Wendler <ubuntu@xxxxxxxxxxxxxxxxx>]

Hello,

Am 22.05.2010 01:11, schrieb Jan Claeys:
> Op vrijdag 21-05-2010 om 08:26 uur [tijdzone +0200], schreef Philipp
> Wendler:
>> 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.

But this adds inconsistency again. Both VLC and rhythmbox are media
players. And VLC is not useless for listening to music in the
background, on the contrary I (have to) use VLC for listening to music
sometimes because I have music files that rhythmbox doesn't play (right).

> 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.

You cannot clearly determine the intention of the user in all cases. VLC
can be used for background listening, and rhythmbox can be used for
foreground tasks like looking through the music library and playing
short parts of a lot of audio files.

> 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!).

I'm afraid this won't happen. I believe a lot of people use the web as
(one of) their primary media source(s) through sites like Youtube etc.,
and how would you use a dedicated program for this? In a lot of areas we
see the trend that stuff which was previously done by dedicated programs
is now done with websites in the browser (e.g. email), and I don't think
you can reverse this trend for media playing.

> 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.

And how does the user know the difference? I think the only effect for
the user would be that in some cases his music player suddenly stops and
he wonders why.

Also I don't think that the current situation is a problem.

Greetings, Philipp