Can I put more than an icon. Like an icon an some text, like the
current (gnome 1 and 2) GnomeICU applet ? Am I allowed to blink the
icon? (ie when a message comes in?) 

Since I've seen not a single proposal for this, I'll make one.

Only icons and flat images are permitted in the notification area.

Design of icons is specified in the HIG.
1) Icons representing physical devices should use the table 
   perspective with the light source above and to the left of
   the represented object. (E.g., a printer icon during printing)
2) All other icons should use the shelf perspective with overhead
   lighting. (E.g., an envelope icon when mail arrives)

Flat images may be used for perpetual displays which change over
time, such as load meters. The space of a flat image must be
clearly delimited. For example, a load meter which which displays
a scrolling green bar graph on a black background should have a
one black pixel border.

Icons should not usually appear animated. The may change to
indicate a change of state, but should not do so when that change
is occurs regularly rapidly. A battery status indicator would
usually change slowly, therefore an icon is appropriate. By contrast,
a load meter would always be changing, therefore it should use a flat
image.

(Brief summary: No buttons. No Looney Tunes.)

The utility of the notification area decreases rapidly when more than
(some number) of icons are always present.

1) Only core GNOME programs may
   a) perpetually display an icon, or
   b) use flat images.

2) Non-core programs for which a perpetual icon may be useful
   a) must defualt to not perpetually showing the icon, and
   b) may present an option to perpetually show the icon.

Henceforth "icon" means an icon or a flat image.

Icons are permitted to blink under a few conditions.
1) An icon may blink for n (=5?) seconds when first displayed
   if showing the icon is not caused by user action.
   A printing-in-progress icon would be shown because the user
   is printing a document, therefore it should not blink.
   An incoming email or personal message (IM) would be shown
   because something has changed absent the user, therefore it
   may blink.

2) A icon may blink for n seconds if its conditions for initially
   blinking recur. For example, an incoming email icon which was
   shown and blinked when a message arrived and which has remained
   visible may blink again when another message arrives.

3) Any icon may blink to indicate an error in deference to showing
   an alert. For example, a printing-in-progress icon may blink when
   there is a paper jam, but not when the printer is on fire - that
   should show an alert.
   (Short summary: Blink or alert, but not both.)

Icons should respond to the these user actions.
(Keypresses apply only when the icon has focus, of course)
  1) Double-click or Enter-key.
     This should show a window with relevant data.
     Examples:
     - the printer queue for a printing-in-progress icon.
     - the inbox for an incoming email icon
     - the message for an incoming message
  2) Right-click or Shift-F10.
     This should present a menu for the icon containing at least
     the default (double-click or enter keypress) action.

If the icon's properties may be altered, it should:
  1) Have a menu item "Properties" in its menu.
  2) Show its property panel in response to Alt+Enter.

Icons should obey normal tooltip conventions.

...

That's a start. I may append more later.

Is it allowed to minimize an application into the tray icon? (example,
GnomeICU would minimize not into the taskbar, but hide the whole main
window and just let the icon visible)

i disagree with "double-click" - launchers react to a single click,
status icons shoudl react the same.  Since most applications that have
a status dock will show a window upon "activation" (be it single
click, double-clock, or whatever), they are to the user very similar
to launchers:

a launcher for galeon, you click on it, you get a galeon window.
a printer status icon, you click on it, you get a print
queue/properties window.

If the status docks are going to be "double-click", then so should be
launchers, and any other icons on the panel.

Also, so far as the question about hiding main windows for apps on
clicking the status icon, it is fuzzy; clicking a launcher doesn't
close a window it just opened, but instead opens a new one.  Of
course, for status docks, this isn't the situation you'd generally
want.  As activating the status dock should generally open/focus a
window, clicking again should have some action; given the number of
apps in other desktops (kde, windows) which hide windows in this case,
it's rather become accustomed behaviour (indeed, this is already the
behaviour of the gaim status dock).  Certainly having it do nothing in
this case would be confusing to the user.

Whatever is decided, it should be consistant.  Also, I've not seen the
api in gnome2 for the status dock clients, but hopefully there's
something simple that also guides/enforces the standard; i.e., make it
so you can only define an icon, activate callback, and context-menu,
and then calls for "change icon status", "popup message/warning",
"flash animation", which themselves enforce the timeouts and such. 
Otherwise we end up with the dialog button ordering problem, where 
alot of 3rd party authors make custom dialogs with "broken" button
ordering because the code didn't enforce it on them in the slightest.

I'm not convinced that timing out blinking is a good idea.  If I'm
looking away from the computer for a few seconds (to talk to someone
who has walked by), or even just intently studying something on the
screen, I may miss an icon that only blinks a few times.  I would much
rather this be left up to the application to control.  As an example,
IM applications should not blink incoming messages when set to 'away'
or 'do not disturb' type statuses.  Other classes of applications
should have similar guidelines, but I don't think it makes sense to
have this be specified for all applications in the HIG.

As for the double-click, I'm not sold on that either.  Certainly
nothing else on the panel requires double-clicking, and this is pretty
clearly part of the panel, and not part of the file manager (and thus,
the "desktop").  I don't understand the rationale behind this.

*** Bug 100930 has been marked as a duplicate of this bug. ***

We also need some guidelines about what should be on the menu, e.g.
one thing I'm thinking is there should always be a "Remove Icon" menu
item that hides the icon, and you can turn it back on again from the
application's Preferences dialog.

This idea assumes that only applications are allowed to present
notification icons... is that reasonable?  Or is there some class of
notification icons that would never have an associated application,
that you want to add directly from the Add to Panel menu?

Along with my recent proposal to usability@, icon hiding should be
exclusively the domain of the notification area prefs.

  http://mail.gnome.org/archives/usability/2003-June/msg00233.html

I'll be sending a revised proposal Real Soon Now, which will
take into account comments on the first one.

I've added a really rough draft of this stuff (using the text from
Greg's original proposal, above) to the Desktop Integration chapter. 
I know more discussion has taken place since then but I don't have it
all to hand here at the moment... perhaps Greg can oblige by updating
the HIG as required, or at least pointing me at his latest proposal :)

For reference, here's links to the notification area guideline
discussions that happened on usability and xdg lists:

http://mail.gnome.org/archives/usability/2003-March/msg00039.html
https://listman.redhat.com/archives/xdg-list/2003-March/msg00060.html

Also a related discussion from KDE land:
http://lists.kde.org/?t=104414525400003&r=1&w=2

I recently posted a new much stricter proposal for usage of the
notification area. According to that proposal only two case are valid
usege, everything else is misuse. These cases are *notification* and as
*status monitor*. I think all problems with misuse can be solved
permanently if the following is done in this done:

1) Forbid all usage that is not either *notification* or a *status
   monitor*. This is very similar to what is already in the new HIG
   draft, only a little stricter.

2) Develop a standard for *status monitors*. They should function
   like cross environment applets. The main benefit from is is that
   monitors should be explicitly added for display by the user.
   Applications often thinks it's status is super interesting, users
   might disagree. (It has to be *really* interesting before I would
   want it permanently displayed on my screen).

3) Develop a completely new standard for *notification*, and
   notification only (perhaps a small subset of the current
   systemtray spec). It will shift over most responsibilities from the
   applications to the notification area. It will make it easier for
   application developers and users alike.

4) Have support (in the notification area) for both specifications a
   while but strongly discourage all use of the old one. And then at
   some point drop support for the old one (the problem can not be
   completely solved while that is still around).

Greg reminded me of another link that might be of interest...
http://java.sun.com/products/jlf/at/book/Alarms.html

Microsoft's guidelines are on this page:
http://msdn.microsoft.com/library/en-us/dnwue/html/ch11f.asp

I'm reopening this. Of course we need info; that's the case for just
about every bug that isn't a typo. Reserve NEEDINFO for unintelligible
or incomplete bug reports that aren't invalid. As the bug status pages
say:
NEEDINFO
  More information _from_the_reporter_ is needed to proceed further
  in fixing this bug.

(Can the EM tag be used in comments? <em>Test</em>)

Here is my .02

The HIG should be very strict on use of the Notification Area [NA] in
order to prevent misuse that will end up confusing users.

I see a very clear distinction on what should be allowed, there are
most likely lots other cases I haven't thought of, but I hope those
are only edge cases.   As I see it, only _notifications_ should be
allowed in the NA, applications with a constant status change can be
allowed to use the NA, but those without constant status changes
should not be able to loiter there.

Examples:

New Mail notifications may appear in the NA because they are reporting
the arrival of new mail, which is a status change (in the mail app)
from not having mail.  If the new mail notification would like to sit
there until the user has acted to view the mail or remove the icon I
can see this as useful functionality too.  If more mail arrives while
the new mail icon is in the NA, then I think a blink similar to what
Greg had posted is reasonable; this should indicate to the user a
change in the original status of the notification icon.  Once the user
has acted on this new mail (or clicked to remove the icon), the icon
should leave leave the NA.   New mail notifications should not loiter
in the NA because mail doesn't have the sense of connected or
constantly changing status; therefore there would be no useful
information to update the user with.

IM Clients are a little difficult, I believe this is related to two
things:
     Client status can change often (connected/away/busy)
     Client presence status needs to be reminded to the user, so they
aren't "away" when they mean to be "available".

One last thing that is strange about these apps:
     Client roster/buddy list windows are a little awkward, they are
meant to be acted on or notify you of events (useful in a state of
flux).  However these IM Client windows cluttering the desktop since
they have no use unless they are in a state of flux. (there are other
apps where we could see this as well)

The coolest solution I've ever seen to this problem is the OS X bar,
where the difference between the app running and the launcher is
negligible.   With this system, you can keep a notification area just
for notifications and applications can be hidden without really
quiting.  I find this to be ingenious, since the user mental model of
application use is much different than the computer model.  The OS X
bar appeals more to the user mental model of applications than the
actual computer model.

So my recommendations are to minimize the use of the NA, I'm ok with
IM Clients (and variants) using it since if we forced them to use
applets the space of the applet on the panel would still be taken up
by the Client even when it's not running.

I take it this would rule out rhythmbox's notification area usage
(which I personally like, but is clearly a hack to solve the
background app/status monitor problem). 

Re: the requirement for the user to explicitly add the status monitor:
would this be a preference of the monitor area or might it be
available in the application, too? It seems that something similar to
the current applet model (where you have to add the applet to the
panel) isn't quite right for real applications whose UI should only be
visible sometimes, but accessible at any time/place. (I'm thinking of
IM and multimedia apps).

More for my own information. Does anyone have a problem with epiphany 
head's use of the notification area for our downloader.

The current behavior is to add an icon for the downloader to the 
notification area while downloads are occuring. Closing the download 
window while downloads are still happening "minimizes" the downloader 
to the tray. Double clicking the icons shows the downloader window. 
When all downloads have been completed, the download icon is removed 
from the notification area.

Dave, I'd suggest going a step further. (I'm assuming that what
you've left out is the same as it has been.) What I'm about
to describe would be MUCH easier with changes to the "balloon
message" part of the protocol, but it'll have to do for now.

1) Show the icon in the tray.
2) Once it is showing (i.e., you've received the first expose event),
   compute its location relative to the root window.
3) Before showing the download window, place it so that one edge
   will line up with an edge of the icon.
4) Set the download window to be border-only, skip the taskbar, and
   skip the pager.
5) Then map the download window.

The effect should be that the download window appears to come out
of the tray icon. It's like a balloon message, but it's more
interactive. (It "comes out" geometrically, not as an animation.)

When the icon is activated (double-clicked, for now), toggle the
visibility of the download window.

Later on, we might get other things to work similarly. I've been
to caught up with other things to write down my recent thoughts on
the matter. (Someone, bring me within speaking distance and hand
me a napkin and pen! ;-) )

Few additions to this proposal:


Tool tip for notification icon:

- Notification icons and panel applets must show informative tool tip, which
must provide sufficient information to identify owning application and purpose
of the applet. There is no need to contain exact program name, especially in
active state (e.g. Downloading myfile.tgz, Playing song tralala.mp3 should be
sufficient).


Continuuous changes. Maybe this can be a consensus:

- Continuously changing icons can be available only at user request. Application
must provide static version of icon (e. g. downloader can provide continuously
changing icon with progress, but it must provide static icon with only few
states - downloading, stalled, complete).


Single click:

Proggramer should decide, what application should do on mouse click.

- Ordinary behavior should be: If window is hidden, show the window. If the
window is invisible/on the other workspace, activate the window. If the window
is visible and on top, hide the window.

Discussion: Activate the window means moving the window to actual workspace or
moving view to workspace of window location.

If it has any meaning to open new instance/window, it can open new window
instead of hiding existing window.

Application author can decide to open window as persistent on all workspaces, if
it has any meaning.


Close button behavior. Article to discussion:

If application has notification icon and if it has reasonable meaning, pressing
close button should only hide the window. Application menu and context menu of
icon must provide full quit menu item. It extends comment #7 from Calum Benson.


Daemons:

Desktop daemons can have notification tray icon, which can indicate, that the
daemon is running and daemon state. Context menu must provide a way to quit the
daemon. (Example: Bluetooth OBEX server)

Article to discussion: What should do daemon applets to mouse click?

>Close button behavior. Article to discussion:
>
> If application has notification icon and if it has reasonable meaning, pressing
> close button should only hide the window. Application menu and context menu of
> icon must provide full quit menu item. It extends comment #7 from Calum Benson.

I strongly object to this version.. I feel that having that closing the
application's main window do anything else than closing the application is just
wrong (even if windows MSN or Gaim do it).

> Daemons:
> 
> Desktop daemons can have notification tray icon, which can indicate, that the
> daemon is running and daemon state. Context menu must provide a way to quit 
> the daemon. (Example: Bluetooth OBEX server)

Do they really belong there ? We dont want the notification area to become
overcrowded like the windows systray. Daemons should use a capplet like vino
does. They should only show an icon in there when they have something to notify. 

Close button:

This gaim feature is ergonomic - you don't have to move your mouse pointer to
move over the whole screen to hide the window. But you are true, it is strange
and unexpected behavior.

For BFU, pressing iconify button looks strange, too. They have two GAIM icons in
panel then (one in tray, one in window list).

I don't know, whether it is technically possible, but Minimize/iconify WM hint
(or new WM hint and icon, middle click to close button etc.) should be more
logical for hiding window to tray and still ergonomic.


Daemons:

I really don't know, what is the best solution. For example - somebody wants to
monitor Bluetooth transfers and quit it ASAP, another user runs it for the whole
time.

It implies another problem - availability of "Silent desktop" - imagine you need
to do an important presentation or record composition in the recording studio,
and you want to suspend all desktop daemons, to disable disturbing - no requests
for Bluetooth transfers, no Evolution appointments, no screensavers, no instant
message appointments...

----

Another proposal to discuss - "killall gnome-panel":


Notification area disappearing

Application must survive temporary disappearing of notification area
application. Application should re-insert its icon, when notification area is
available again.

Application must retain availability, even if notification area application
disappears. The simplest solution is unhiding main application window, if it is
hidden.

Notification area disappearing: This is exactly what gnomeicu does... if the
panel dies, it shows the main window and re-inserts itself.. I think gaim and
gossip do the same. 

For gaim, it just shouldn't sit in the system tray area all the time. There's no
reason for it to. It is only really helpful for accessing the "Away" menu
quickly, but I think that is due to the fact that the menu layout in the main
window is somewhat suboptimal as well. Having notifications when something
happens is useful though, so notifying the user of pending new messages and
such, makes sense.

Windows just should not be minimized to the notification area/system tray, ever.
It isn't a task list. It is an area where we should provide notification and
useful bits of system status. New mail notification, battery status, and network
connectivity are all useful. Minimizing applications to the area, isn't
particularly. And users never really know what to expect, as everything in the
notification area (and also in the system tray on windows), behaves
inconsistently. We really shouldn't promote that possibility.

We shouldn't suspend other parts of the system, or remove the panel, and such,
to make it better for doing presentations and such. We just need to fix the
integration between the presentation "mode" application(s), and the rest of the
desktop, such that it isn't a problem. The presentation app should just be able
to say to the rest of the desktop that it is in presentation mode, and then the
notification bubbles will just not pop up. However, there are certain cases
where in presentation mode, you will want to have notification. If your battery
is about to die, for example, what is worse, having your laptop just shut down
completely in the middle of the presentation, or having a little notification
urging you to connect a/c power to the machine. :)

Gaim tray icon is optional. If you don't like to see new messages in auto-opened
windows and hear sounds, blinking notificatification icon is optimal. It has
perfect configurability to fit all all users' need.

What is confusing for BFU, are two icons in two applets. I don't see simple
solution.

Presentation/non disturb mode should be opened by new bug report - it has more
aspects - notification area, sounds, pop-ups, screensaver. Only the first covers
this bug and only the last one has already solution.

The gnome-panel issue was discussed in https://launchpad.net/products/ekiga/+bug/31763 as well.

Some guidelines for notification icon spacing/padding are needed too.

Is this the new mail notification bug? If so, it would be nice to integrate the solution shown here: http://beranger.org/index.php?article=1346

I strongly agree with comment #14 and have opened bug #470101 to ask for enhancing the task list with features currently provided by the notification area.

Windows should not minimize to tray because the user then has two places to look for running applications.

I think the hole thing about the traybar and task list is due to the task bar has limited space and looks messy when having many windows open, therefore devs of applications that tends to runs from boot to shutdown, like pidgin and rhythmbox makes and "minimize to tray" function.

I think the right thing is to reconstruct the taskbar to be able to have many windows without looking messy. The needs for minimize to tray will then disappear.

I've done a Feature Request similar to this, bug #554979 however, I bet on that changing the task bar in some way is the way to go. Tray bar would then only bee needed for stuff like NM and System updates 

Sorry we never really got around to finishing the notification area guidelines in the GNOME 2 HIG, but we don't plan to update that document any further now. If you feel any of the issues discussed are still relevant in GNOME 3 and need addressing in the GNOME 3 HIG, please file a new bug.