zrusin at trolltech.com
Thu Feb 2 18:30:32 EET 2006
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
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 = x timestamp (or 0 if none is available) l
> > = action type (see below) l = 0 l = 0 l = 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 = x timestamp (or 0 if none is available) l = window
> > id of tray icon l = action type (see below) l = 0 l = 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 MSW = x, LSW = y, and l 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 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"
If it is not on fire, it is a software problem.
More information about the xdg