unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

Jacob Peddicord wrote:
> A close button I personally don't see being useful, in the current
> state of how notifications are displayed. They come and go relatively
> quickly, and by the time you notice a notification to click the X it
> may have already disappeared.
I agree.
> Actions would be the obvious argument for a hidden option, but this
> has already been debated to death.
We won't bring actions back, even if a patch is contributed to do so.
The user experience of "racing to click on the action" is fundamentally
broken, and can't be fixed even though many people will clamour for it.
So, actions require completely different presentation - we think they
should either be in windows which call for attention, or in dialogs. Our
current action handling is a half-way house to tolerate badly-behaved
apps while they get fixed.

> I can think of plenty of other options that would be nice though:
>  - Positioning and size
>  - Default expiration time
>  - Theming? Different colored backgrounds/font color, etc for those
> with different GTK themes
>  - Stacking notifications vs queuing. The default behavior is to queue
> up notifications and display them one after another, though with an
> active Gwibber you might have non-stop notifications appearing. The
> ability to have them stack on top of another, possibly with a limit of
> how many could be on the screen at once (as a user-configurable/gconf
> setting?) would be nice.
Patches for any and all of these would be considered and have a chance
of being accepted; though by no means a guarantee of being accepted.

On positioning, we want to experiment with a move to half-way down the 
right hand side of the screen (clearly not ideal, but it may help to
alleviate some issues while not creating others). The synchronous
notifications (brightness, volume) would always be on top, in a fixed
position, just above the mid-point, while the async ones would be below
the mid-point. There is technically room for multiple async ones.
Biggest problem would be figuring out how to handle appends to a higher
notification, sliding lower ones down. We think that's badly enough
broken that queueing is better, but your patch may show otherwise :-)

> I have to admit, when I first saw notify-osd a few months ago, I hated
> it. But now that more applications are supporting the system, it feels
> *a lot* better -- not perfect, but better.
Thank you for saying so. I know it was a big risk to take on something
this visible and this widely used, but the goal was to learn about some
of the hard problems (like whether we can survive the short-term social
cost of taking something away, like actions, if we're confident the
long-term result is better).

Mark

Attachment: signature.asc
Description: OpenPGP digital signature