Why the notification area takes a window, not an icon.

[Gregory Merchan <merchan phys lsu edu>]

Since an API for tray icons is being discussed, I offer this in the hope that
it is useful to someone.*

There are a few reasons why the notification area protocol uses a window
instead of an icon.

1) History: The current protocol was conceived as a cross-desktop applet
   protocol. Later, the problems with the old status dock became apparent.
   I presented my original protocol to solve that problem because: 1) it did,
   and 2) it would make common the code to share applets later.

2) History II: Windows were used by other similar things; e.g., icon windows,
   applets, WindowMaker docklets, old status docklets.

3) Clock: The desktop clock on Windows sits in the tray and I thought it
   would be nice to be able to do that. Restricting the tray to icons would
   forbid it.

4) Animations: Repeatedly sending an icon to the tray to achieve animation
   would waste resources. The first use for animation that comes to my mind
   is a load monitor like IceWM's. While I'd consider briefly blinking an
   icon to be the only good animation, I didn't want to impose that on
   anyone else.

5) Freshness: If the tray draws the icons, it must also make sure the app
   providing the icon data is still running. Because the embedded window
   is a resource of the app client, it disappears when the app client dies.

6) Image Scaling: Using the size given to its window, the app should draw
   an appropriately scaled icon. Sending icons would require either rescaling
   by the tray or checking a property for the correct size.

7) Visibility Information: Because an app can detect the visibility of its
   window, there's no need for the tray to send such information.


I think, though I'm not sure, that using an embedded window instead of
transmitted icons uses fewer resources. The cost of this is the guarantee
of UI consistency.

It would not be difficult to devise an icon transmitting protocol.
Should that be done, I hope that, while the code is being changed, the
baloon message handling is changed to a token-based system, or to allow
html, or at least to have the message retrieved from some window property
instead of being sent by ClientMessage battery. A token-based system would
be like a token-ring network; the token granting permission to show a window.
Allowing html would make messages actionable by link or widget. (See the
Windows product ZoneAlarm for an example. In the Flash demo one their website,
there's shown a balloon message with the words "ZoneAlarm Pro Alert" at the
top. It's about mid-way through the cheesy "demo".)


Cheers,
Greg


* And if it wasn't useful, please say nothing. I've had nothing but grief
  since I looked at the problem with the old status dock.