thoughts on the systray

[Havoc Pennington]

On Mon, 2005-02-14 at 10:59 -0700, Aaron J. Seigo wrote:
> > This is a different problem space than what we discussed at XDevConf.
> > You're talking about some form of notification system here, our
> 
> if you mean a "notification system" in the sense of what we have in KNotify, 
> no. if you mean a "notification system" in the sense that the application 
> wanting to appear in the system tray and the system tray itself (which may be 
> a non-gui representation for e.g. accessibility) communicate via IPC, yes. 

OK, so my view on the system tray is that it's legacy. I don't think
there should be such a thing except for back compat and windows compat.

I think there should be a way to say "new mail" or "new IM" or whatever
(notifications), but a priori have no reason to believe that involves
tray icons. Maybe it does, but I don't have any reason to believe that.

Maybe that's the unclear point?

> it's that last part that gives me chills. the system tray spec sucks and i 
> don't want to spend the next 3-5 years maintaining similar suckage for panel 
> applets. if we open the doorway to XEMBED applets as a x-platform standard 
> for KDE4, it won't be removable for a long time. this is a non-trivial 
> decision, and i would far prefer something that allows me to make kicker more 
> than a lobotomized gray rectangle. i understand the needs of applet writers, 
> but please consider the needs of panel writers and the users who rely on 
> those panels.

My view here is that if you support in-process applets, someone can
always write an in-process applet that happens to embed or swallow an
out-of-process thingy. And a cross-platform out-of-process spec is no
more constraining than that. It's pretty much OK to say that in-process
applets work better in some ways.

> the GNOME XEMBED implementation allows me to take a popupmenu that lives in 
> the applet's process and manipulate it and then show it in the host panel's 
> process? this is the trivial example i keep using because: a) it's trivial 
> and i haven't seen it able to be done yet, and b) it's a real world example 
> used by kicker.

We talked about this and agreed that it was simple for the panel to
provide the standard panel menu items to the embedded applet. Of course,
for GNOME these are just "Remove From Panel", "Lock", and "Move" - I
don't know what specific menu changes you have in mind.

> >  - "some kind of notification system designed top-down"
> 
> i don't think this is in-scope here. in KDE notifications are much more than 
> what we're discussing here and i think that makes sense. 
> 
> i keep trying to describe a system tray that works over IPC and you and Owen 
> keep coming back at it with "notification system". i hope this is just a 
> communication error where we are using different words for the same thing.

For me at least it's because I don't care about the system tray; I think
there are two useful things, 1) applets and 2) some kind of notification
system, and I don't think the purpose or value of the system tray exists
- except for back and Windows compat. Given that the main point is back
compat, and tons of apps are using the current tray spec, we sort of
have to keep supporting the current spec. At that point we may as well
add a new spec that does more useful stuff.

Oh, another thing that can help replace the tray would be extensions to
the taskbar so you can maybe spice up your app's taskbar button.

Havoc