thoughts on the systray

[Aaron J. Seigo]

On Tuesday 15 February 2005 07:05, Havoc Pennington wrote:
> 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.

of course not; to do so would be to ask the wrong question. the question is 
how are these messages delivered. and if we look at the reality of the 
situation and see what application developers actually try and accomplish 
today with the various "types" of system tray usage, simple notification is 
not enough.

> Maybe that's the unclear point?

i see. see the very end of this email for how we're not so far off. but at the 
same time, i don't see the system tray going away or not being offered for 
new development and concepts in the future. 

personally, i see the need to continue to support, for the same legacy reasons 
you note, simple embedded icons.

i also see the need for lightweight, IPC-driven interfaces that appear in the 
panel. this should largely replace the current systray usage in new 
applications.

and of course, applets.

> 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.

we already have such a thing and it basically works: appletproxy. it's XEMBED 
based, swallows applets whole, embeds into kicker, yadda yadda. been there, 
done that, hated it. it creates inconsistencies and subtle bugs. it's easy to 
do, and also a detriment to quality and flexibility. i'm speaking from 
experience here, not theory.

> It's pretty much OK to say that in-process  applets work better in some
> ways. 

yes.

> > 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.

if you look at kicker, every applet has a little "handle". in that handle is a 
menu. in that menu is a submenu that comes from the applet. this allows us to 
put an arbitrary, applet created and owned, custom menu that is specific to 
that particular applet in a standard location so users can find it. most 
applets choose to place their context menu there to make it easier for users 
to find.

so this isn't about passing a few static type items around and modifying 
menus. we do that with the system tray items out-of-process right now. this 
about manipulating menus in a cooperative fashion between the panel and the 
applet as you would _any other gui element in an application_. 

you see, an applet is not simply something the panel hosts, it is something 
that extends, interacts with and modifies the panel itself. the more we can 
move in that direction, the more useful the panel can become.

> 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.

yes, and i think a properly written "systray++" spec would enable this. when 
i've been describing my hopes for a new systray spec, i've clearly stated 
that the division between publishing the information that the application 
wishes to have represented in the interface and that actual representation be 
made very clearly, with IPC (likely DBUS) being the medium for doing so. this 
way we can continue to offer familiar and highly requested features to 
application developers while allowing us to be innovative and creative in how 
we service those features in the user interface.

in other words, when i say "system tray" i'm thinking not so much of that 
applet that takes a few hundred square pixels as i am thinking about the 
information it represents and the communication between that representation 
and the applications represented by it.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050215/f2832619/attachment.sig>