systray specification...

[Zack Rusin]

On Thursday 02 February 2006 15:21, Bradley T Hughes wrote:
> > i dont's ee we need to worry too much that we aren't using shm
> > transport to send the data, as it should not be so much, but you
> > have a very good point of being able to save data/bandwidth/memory
> > by specifyin a name and also being able to upload multilp icons and
> > attach them to a window then select which one to use.
>
> indeed... how we transport the data is uninteresting... avoiding
> unnecessary transfers is, though ;)

in here we might as well do it properly and add shared surfaces to x - a 
way to query by name (id) and reuse drawables used by other 
applications (possibly in a read-only way). a quick add to xfixes and 
xrender should remedy that. 

> yup, sounds just like what I was thinking... I had considered making
> the icon data an array of _NET_WM_ICONs, but that means the system
> tray would be required to fetch all icons again if only one of them
> changed.

so we're basically saying animation == series of pixmaps, rather than a 
surface that changes (as in "drawing to it"). i don't really have a 
problem with it, but like i mentioned above we can fix it properly :)

> > mouse enter = hilight, mouse leave = unhilight etc. (or whatever it
> > sees is appropriate - but consistent between all systray icons).
> > this way a user now KNOWS of a set of interactions within their
> > enviornment that always work the same. they change it 1 place and
> > it all changes consistently. there are only a few things we need to
> > handle here. what information to send? well lets specify this a bit
> > better
> >
> > a client message with atom _NET_SYSTEM_TRAY_ACTION, fotmat 32 is
> > sent TO the tray icon window by the tray manager. the data payload
> > is as followers l[0] = x timestamp (or 0 if none is available) l[1]
> > = action type (see below) l[2] = 0 l[3] = 0 l[4] = 0
> >
> > action types: 0 = SELECT (eg: a single click or press spacebar) 1 =
> > ACTIVATE (eg: a double click or press enter) 2 = HOVER_IN (eg:
> > mouse enters the icon or focus is tabbed into the icon) 3 =
> > HOVER_OUT (eg: mouse exits the icon or focus is tabbed away from
> > the icon)
>
> Looks good to me.

Right. Just when formalizing it please try not to advise on click 
behavior. We're trying to move away from double click and having specs 
reference it all the time is a little confusing to people :)

> > i also think that the application owning the systray icon shoudl be
> > able to send "meta" events back. instead of every app blinking its
> > own icon for example - the systray will do it FOR the app (blink
> > may mean pulsate for the systray, or glow, or go from faded out to
> > in and not animate at all - whatever the tray manager and its
> > configuration deeems is appropriate to notify a user of some
> > urgency). so if the tray icon wants to send events back it should
> > send a client message to the tray owners selection window of the
> > atom
> > _NET_SYSTEM_TRAY_ACTION of the format 32 and the data payload
> > being: l[0] = x timestamp (or 0 if none is available) l[1] = window
> > id of tray icon l[2] = action type (see below) l[3] = 0 l[4] = 0
> >
> > action types: 0 = NORMAL (display things as normal) 1 = INTERESTING
> > (something interesting happend but its not that important) 2 =
> > URGENT (something urgently needs attention right now) 3 = DORMANT
> > (the systray owner is now dormant and shoudl be ignored)

Uuu, that's a good idea :)

> > as for thnigs like sliders - it may be possible to cover this too -
> > if there are no other "sane" uses we are likely to see (i would
> > argue looking at the gnome HIG bug thread even this is an abuse of
> > the systray/notification area) maybe we can cover it too.. if not
> > the only opther thgn we need to do is indicate the geometry of the
> > icon that was activated/clicked on screen relative to the root
> > window. if there are multiple copies of it - then this needs to be
> > piggybacked on the action messages above. i might suggest using
> > 16.16 encoding -ie l[2] MSW = x, LSW = y, and l[3] MSW = width, LSW
> > = height of the action message the tray manager sends to tray
> > clients?
>
> That sounds acceptable to me. We could even put the x/y coordinate of
> the button event in l[4] if we decide it's needed and/or useful.

this is getting pretty complex for a simple spec. i'm not saying that 
consitant menus wouldn't be great, but what i'm afraid of is that there 
will be legitimate cases where none of this is enough and i think we 
definitely have to cover sliders. mixers are one of the most frequent 
icons in everyone's tray.

> > ... i hope i got the idea across anyway.
>
> Yes, you did :) The only thing I'm unclear about is how the systray
> decides whether to show a menu, or to send the action. Should we
> always send the activate, and the client has to respond with an "open
> menu" type of message? Or should we "select" for what should happen
> in response to various button presses?

i think select should be sent before showing the menu. activate should 
be reserved only for when interaction with the parent app was 
requested. for example right click on an item would invoke, select and 
then a menu would be shown, exit from a menu should most likely cause 
deselection of an item as well.

Plus, I'd like to point out a few more things which have been nicely 
sumarized by Aaron in his "What's Currently Wrong With the System Tray" 
writeup here:
http://aseigo.bddf.ca/cms/1092

Zack

-- 
If it is not on fire, it is a software problem.