--nextPart8348920.Dgk44j33eE
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
how are these messages delivered. and if we look at the reality of the=20
situation and see what application developers actually try and accomplish=20
today with the various "types" of system tray usage, simple notification is=
=20
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=20
same time, i don't see the system tray going away or not being offered for=
=20
new development and concepts in the future.=20

personally, i see the need to continue to support, for the same legacy reas=
ons=20
you note, simple embedded icons.

i also see the need for lightweight, IPC-driven interfaces that appear in t=
he=20
panel. this should largely replace the current systray usage in new=20
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 XEMB=
ED=20
based, swallows applets whole, embeds into kicker, yadda yadda. been there,=
=20
done that, hated it. it creates inconsistencies and subtle bugs. it's easy =
to=20
do, and also a detriment to quality and flexibility. i'm speaking from=20
experience here, not theory.

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

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 i=
s a=20
menu. in that menu is a submenu that comes from the applet. this allows us =
to=20
put an arbitrary, applet created and owned, custom menu that is specific to=
=20
that particular applet in a standard location so users can find it. most=20
applets choose to place their context menu there to make it easier for user=
s=20
to find.

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

you see, an applet is not simply something the panel hosts, it is something=
=20
that extends, interacts with and modifies the panel itself. the more we can=
=20
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. whe=
n=20
i've been describing my hopes for a new systray spec, i've clearly stated=20
that the division between publishing the information that the application=20
wishes to have represented in the interface and that actual representation =
be=20
made very clearly, with IPC (likely DBUS) being the medium for doing so. th=
is=20
way we can continue to offer familiar and highly requested features to=20
application developers while allowing us to be innovative and creative in h=
ow=20
we service those features in the user interface.

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

=2D-=20
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

--nextPart8348920.Dgk44j33eE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCEi8z1rcusafx20MRAlyaAKCk6njjDQHTOBD8q+DVJPX26/Wm9wCgqvbK
EYwlQ1MWrtJbsK4jA1u9x1U=
=Kznv
-----END PGP SIGNATURE-----

--nextPart8348920.Dgk44j33eE--