thoughts on the systray

[Havoc Pennington]

On Sun, 2005-02-13 at 15:58 -0700, Aaron J. Seigo wrote:
> the idea i'd like to see for the system is thus:
> 
> 	o a DBUS bus that applications can publish "i have a system tray entry, here 
> are the details of it". the application would update this information as 
> state changed. think about autohiding icons, for instance, and the need to 
> know the current state of an application (idle, important stuff happening, 
> etc).
> 
> 	o host apps (e.g. the systray applet in kicker) would consume this data to 
> present an interface. the interface would be 100% under the control of the 
> host app, including what to do when the user, for instance, right clicks on 
> an entry versus left clicks on an entry.
> 
> the application with a systray entry would only publish data, (and receive 
> event notifications, for instance "the user wants to see a context menu for 
> this entry") and not have anything to do with the actual presentation or 
> management of the GUI. this immediately puts some limits on the system tray, 
> allows the host app to sanely and powerfully manage the information in its 
> display and separates the publish/display actions.
> 

This is a different problem space than what we discussed at XDevConf.
You're talking about some form of notification system here, our
discussion of that was "we need to know what the interaction designers
want it to do, then we can discuss it after that" and we moved on.

For applets the people in the room (Owen, Lubos, clee, Lars Knoll,
myself, probably I'm forgetting someone) felt we had a better idea what
the desired design would be like. (Maybe we didn't, though it sounds
like you're disagreeing on implementation, not design.) What we
discussed was to have both in-process applets (which would be desktop-
specific) and out-of-process (which would be sort of like the system
tray spec).

As an aside, I think most of your XEMBED problems were probably due to a
bad implementation of it; I don't think the Qt XEMBED widget was ever
really finished? I could be wrong. But anyhow, that spec works fine for
GNOME applets and such.

I agree with you that some kind of script approach (like Apple
Dashboard) would be very interesting.

Can we keep conceptually separate the various discussions though:
 - applets
 - "some kind of notification system designed top-down"
 - support Windows-style tray icons
 - how to implement vs. what the design specs are

I feel that we have to continue to support the current tray icon spec,
since *tons* of apps are using it; and given that, it may as well be the
answer for "Windows-style tray icons"; for a new spec, we should start
with a designed UI that makes more sense. Tray icons are a broken idea
inherited from some ancient Windows version, MS itself keeps trying to
get rid of them; we should just support them as a back compat thing and
replace with some better-thought-out features.

Havoc