Systray specification

[Aaron J. Seigo]

On Friday 07 March 2008, Toma wrote:
> 1.3 The spec should use the NETWM_ICON property to deliver an ARGB image to
> display. The tray can scale, draw, composite or whatever it wants. It can
> no create multiple copies. If the icon needs to change - a property change
> will do the job. Doing more is probably abusing systray icons far beyond
> what they should be used for.

i think there are better options than NETWM_ICON, tbh (look at the first hit 
on google for NETWM_ICON ;)

that said, it would be great if it were possible to instead optional also 
provide an icon name which could then be looked up in the current icon theme. 
we can't get rid of pixmaps in their entirety (animations, overlays, etc) but 
it would be nice to see if we can get away from always pushing pixmaps around 
for the common simple cases.

> 1.4 As such systray icons have just become a way for applications to
> avoid showing a
> main window but stay running. They function often simply as a replacement
> for iconification in icccm. Thus using the same mechanism is the better way
> to go.

this is true of some (ab)users of the systray, but certainly not all apps. 
it's a very convenient and appropriate way to sho, for instance, network 
manager interfaces, xrandr controllers or master volume controls.

> 2. As such icons want some form of interaction with users - do be able to
> click on them to activate something or pop up a menu/dialog/popup of some
> sort.
>
> 2.1 We should implement a protocol via which an application can
> advertise some form of
> menu/popup structure to the systray so the systray can consistently
> implement menus on all systray icons in 1 style and 1 unified look. This
> falls in line with what is done in qtopia for the menu window (they use
> qcop to deliver this data) and with hildon on the n770/800/810 and the
> separated menu window. It would absorb this functionality as a unit on its
> own

do these systems actually publish a menu structure which is then shown 
in-process to the system tray host, or do they simply receive a point on 
screen from which to show their menu?

> 2.2 In the case a systray cannot display what is needed being able to pass
> events (mouse motion, enter, leave, press and release events) as well as
> location of the tray icon relative to the root window.

this is probably more realistic, as it's easier to not screw up and would 
require a lot less changes in application code.

> This way -
> 1. The tray icons can be displayed with a consistent look irrespective
> of the toolkit or tray application.
> 2. It can be placed in more than 1 location if desired.

this problem is actually somewhat lessened by the increasingly common use of 
off-screen rendering, but still, it's the long way around to achieve that.

> 3. It can have a consistent look of any popup menus and controls and a
> consistent set of interaction
> 4. Will match more with the usage of the tray spec,
> 5. Roll in other systems of abstracting this kind of "out of window
> control" element from other UI systems (qtopia, hildon)

yeah, i'd really like to see this happen too. it requires someone to write the 
spec and start with implementations ... we've sort of all been staring at 
each other for a few years now waiting for someone to have the time and 
energy to do it.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080307/feaefcac/attachment.pgp