unity-design team mailing list archive

[Connor Carney <ccarney@xxxxxxxxx>]

A sound windicator in Banshee seems like an edge case to me, because
Banshee (a) already lives in the system sound indicator, and (b)
usually runs in the background.  A better starting point might be to
consider something like a sound windicator in Totem, which doesn't
normally have an entry in the system indicator.

Here's the behaviour I would like to see:

1) window floating => application volume in window decoration

2) window maximized and focused => application volume in system sound
menu (with some sort of cue that it's available)

3) any other case => application volume not available

This way, window indicators are always available for the window that
you are interacting with, while indicators for background windows
don't get in your way.  Applications like Banshee that are *designed*
to run in the background can put their functionality in the system
indicator directly.

Connor




On Sun, Feb 20, 2011 at 12:51 PM, Carl Simpson <cwd.simpson@xxxxxxxxx> wrote:
> Annoyingly, this somehow ended up in a completely different thread due to
> the horrors of human error.  I'm reposting here.
>
> Sticking with the examples of Banshee and volume, for the sake of argument,
> we also recognise two sorts of window indicator:
>
> a)  A window indicator that stands alone as functionality dedicated to a
> particular window.  I call these “window-specific” window indicators.
> b)  A window indicator which is a candidate for merger with system
> indicators under a “collapsing” indicator system, because they encapsulate
> system-relevant behaviours.  I call these “system-relevant” window
> indicators.
>
> With the collapsing idea in place, things are like this:
>
> 1. Banshee is maximised.
> Volume controls (as system-relevant) for Banshee are collapsed into the
> appropriate system indicator.  Window-specific window indicators for Banshee
> are present to the left of the system indicators.  No separate window
> indicator for Banshee's volume is shown.
>
> 2. Banshee is not maximised.
> Volume controls for Banshee are in a window indicator, situated on Banshee's
> window decoration.  Volume controls for Banshee in the system indicator are
> now not present.  Other, window-relevant window indicators for Banshee are
> present on Banshee's window decoration as well.  System-relevant and
> window-specific window indicators do not appear distinguishable at this
> stage.
>
> 3. Banshee is minimised.
> ??????  (Banshee's volume cannot be changed?)
>
> My concern is that the functionality of changing the volume of Banshee moves
> about quite a bit.  It does this in two ways:
> 1)  It moves from place to place in the interface- namely between the panel
> and the window decoration of Banshee.
> 2)  When in Banshee's window decoration it literally changes place on the
> screen.
> This will be true of all system-relevant window indicators.
>
> Is such a degree of movement of functionality acceptable?
>
> Something also needs to be said about the case of minimisation.  Does the
> volume control for Banshee end up back in the system indicator, or does it
> simply become unavailable?  Other window indicator functionality would
> become unavailable in the case of minimisation, and it might be argued that
> this is only natural and intuitive.  However, we have two sorts of
> indicators (window-specific and system-relevant), and we have them for a
> reason- namely that some of them (system-relevant window indicators)
> encapsulate system-relevant behaviours.
>
> It is only natural for window-specific behaviours to disappear with the
> window with which they are associated.  Without the window being at the
> forefront, its content does not affect us and the behaviours made available
> by its window-specific window indicators is not important to us.  For that
> reason, having window-specific window indicators tied to window decorations
> seems uncontroversial.
>
> Should system-relevant behaviours, however, such as changing the volume of
> some sound that is playing, be tied to specific windows in this way?
> System-relevant behaviours (such as a playing sound) continue to affect us
> regardless of the position or status of the windows of the applications
> producing them.
>
> Do we really want users to be unable to change the volume of Banshee (or
> alter any other system-relevant thing for any application) when it is
> minimised?
>
> Putting the system-relevant window indicators for minimised applications
> back in the panel adds yet another occasion on which that functionality
> moves position.
>
> Looking at things as they are, I do not think that having window-indicators
> for system relevant behaviours is remotely wise.
>
> If a behaviour is best placed inside a system indicator, my opinion is that
> it stay there at all times at which it is available at all.  In the context
> of the example at hand- Banshee's volume would be present in the system
> indicator when Banshee is running, and available nowhere else at any other
> time.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>