unity-design team mailing list archive

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

On Sat, Oct 2, 2010 at 10:53, Owais Lone <hello@xxxxxxxxxxxxx> wrote:

>
>> buffering Notifications while the user is obviously "busy" would help
>> here.
>> Now if we buffer a notification bubble to display it later on, in order
>> not to interrupt the user's workflow, we also have more "time" in designing,
>> to figure out whether or not we want to display this message in the first
>> place :D
>>
>> these notifications are totally redundant while the sound menu is open and
>> being interacted with. This case is exemplary for a whole category of design
>> flaws we should really talk about, if anybody else cares, also..
>>
>
> That's what I said on the bug. I think this should be handled in Rhythmbox
> itself. If the function is called from sound-menu or the main
> interface, rhythmbox should not send out notifications in the first place.
>
> It should send notifications only when the song is changed automatically or
> with a remote control. Basically, whenever the main interface of the music
> player or sound-menu is not used to change a track.
>

+1

applications that use notifyOSD should do this in a non-intrusive manner.
Currently, Empathy can only be stopped from being intrusive via notifyOSD,
if you untick "use bubble notifications" entirely in Empathy's preferences..
Rhythmbox needs to know if it is being remote-controlled or if USER is
currently focusing the Rhythmbox interface or its derivative in "Sound
Menu".
When the Rhythmbox interface or its instance in the Sound Menu are not
focused by the User's attention, Notifications may be sent where appropiate.