systray specification...

[Carsten Haitzler (The Rasterman)]

On Thu, 2 Feb 2006 17:30:32 +0100 Zack Rusin <zrusin at trolltech.com> babbled:

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

hmm - the one problem i have with this is it makes the spec unable to be
implemented on an xserver that is older. it cant work on an older ncd or x
terminal that doesnt do xrender for example - or an older sun workstation etc.
it'd be nice to allow the spec to work on all xservers without the need for
assuming extensions? in realite the only difference is the lack of drawing
primitives (and almost every systray icon is an icon of some sort - not a drawn
UI - some may be, but that also doesnt seem to be in agreement with systray HIG
guidelines i have look at so far). also the icosn may be so small that they are
useless as drawn UI's as you cannto usefully display information except for an
icon. i do see your point - but i am not sure the benefits are desireable
giving the HIG's trying to limit how systray icons are used anyway, and the
possible miniature sizes etc. etc. i am notsure the systray icons will be
numerous enouhg and share data enough to warrant trying to do any more than
what is already done with NEWTM_ICONs

> > 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 :)

it could be a single icon property whose contents are changed - the choice is
up to the systray client as to how it presents the display contents of its
icon. 1 icon that it keeps uplaoding new pixel data for, or 3 of them it simply
swaps between etc. or some hybrid inbetween.

> > > 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 :)

sure! i am just giving an example here. the systray manager will define the
policy for that desktop as to what input device interaction with the systray
results in what "actions".

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

well thats the idea of sending the geometry in the message - for when the menu
isn't enouhg. i do agree it may be going too far - but there are other issues
such as mouse grabs etc. that need solving for popping up menus. as long as any
mouse grab is release by the systray before a tray client wants to pop up a
menu, then this would work. i am scared defining a menu in properties may be
just going too far here - and this is one thing i'd like some feedback on here.
i know the implementation is a little complex - but even is the idea a bit
much? i'm of 2 minds on this so i can go either way. it has positives as its
just about the most commonly used thing with systray icons, and thus
consistency would be great, but it's also a bit tricky.

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

hmm - i was thinking that since the menu is handles and displayed by the
systray manager then it decides when to display the menu and on what action -
and OTHER actions may indicate selecing or activating. do we need 2? will only
"activate" do? (eg a left click) ?

> 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

just read it - most of the top is exactly what i'm complaining about too. this
is great. the look and feel is hard to control- they look out of place,
inconsistent, etc. etc. and i've only just started gettign my teeth stuck in.

i'm hoping that all of us cna throw our colective weight behind this with
experience and fix it up for the future. i am not fond of being saddled with
the systray as it stands ad-infinitum. aaron touches on very much what i have
touched on here - some minor deviations (a few more text properties - we can
formalise the netwm icon name property and netwm name for the app nam and
optional icon name as aaron lists). i've covered the bitmap i think in great
enough detail - there's still debate on mechanism (x property vs xrender
picture). status is covered above i believe, and we could add another string
for descriptive text too? the actions being sent are covered, though i covered
them in activate, select, hover_in and hover_out (well not all - but the basic
mechhanism - just add more opcodes).

all in all quite the same i was mulling over - if the systray manager does the
menu it can add a default "quit" item ALWAYS - and on quit send a WM_DELETE
protocol req to the systay icon that the app handles like a delete req on any
window - but exits entirely when it recieves it.

the menu is still a debateable point too... but i think there is very much
enough overlap to put everything into a new revised spec. all we need is enough
consensus to agree what needs doing and roughly how - then hammer the full
nitty details and some example code for implementors.

> Zack
> 
> -- 
> If it is not on fire, it is a software problem.
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)