Re: Notification Area guidelines

[Matthew Berg <galt gothpoodle com>]

On Fri, 2003-03-14 at 01:19, Havoc Pennington wrote:
> On Fri, Mar 14, 2003 at 12:12:09AM -0500, John wrote: 
>
> > If we stuck to this rule, red spinning police lights on each of the
> > icons would be unnecessary, as would goofy Clippy-cousin balloon
> > notes. :)  What _might_ be useful is the equivalent of the "master
> > alarm" on a spacecraft...  if a new event arrives, then one main
> > throbber would activate, for instance, and/or a single note from a
> > bell would sound, depending on the user's desires.  The master alarm
> > would stop throbbing when any event on the queue is clicked or
> > otherwise acted on.  The throbber (or whatever it is) could
> > conveniently double as the handle for the notification area widget.
>  
> > Anyway, those are my thoughts, and maybe I'm nuts for thinking them.
> > But, I like the idea of having a central place for events to be sent
> > from background programs to the user, rather than having to pop
> > dialogs up.
> 
> I like that we could actually explain how the notification area is
> different from applets if it's basically an event notification
> service.

Thank you.  Following this thread, it seemed to me that people didn't
have a single coherent idea of what the notification area should be used
for, much less how to use it.

When I first heard of the applet, I assumed from the name that it would
be used as John described (this may come from not having any experience
with XP, so I was going purely on description).  Honestly, I'd love
something like this.  I don't need to waste panel space so I can know
that I have no new mail or IM messages, and besides - it is much easier
to tell at a glance that something happened if icons are added as
notifications come in.

> This whole conversation seems slightly broken to me - we have this
> wacky implementation detail, which is an applet that can contain
> arbitrary icons, and we're trying to figure out some way to use it
> that doesn't suck. But we aren't even sure what the problem is to be
> solved or why we have the thing in the first place. ;-)
> 
> The less-annoying-than-dialogs event notification idea does seem like
> a nail we could hit with our hammer-we-aren't-sure-what-to-do-with.
> 
> Though, I think the hammer is a bit malformed for an event
> notification service, i.e. the spec could be beefed up and enhanced to
> support the right kinds of properties and events on the notification
> icons.
> 
> I guess I'm just making this whole thread inconclusive - sorry. ;-)

It seems to me that if a tool was built without knowing what purpose it
would serve, it's bound to be malformed.  :)

I'm not sure if this has come up yet, but one of the thoughts I had when
I first heard of D/BUS is that it would complement the idea of a
notification area itself.  My understanding of the spec as it stands is
that applications manage the icons themselves.  I would think it would
make more sense to abstract the idea and send a notification message,
especially when it comes to making the feature accessible.

Not having had a chance to read through the D-BUS spec, I can't speak
authoritatively, but I'd imagine it would be possible for the
notification applet to tell the application that pushed a notification
onto the stack when action has been requested on the notification.

(There may be cases where you;d want a persistent icon on the panel, but
based on the application's lifecycle, but it seems to me those muddy the
concept of a notification area, and should be left applets.  If the
panel doesn't handle them properly, it should be fixed.)

-- 
Matthew Berg <galt gothpoodle com>