On Thu, 2 Feb 2006 17:30:32 +0100 Zack Rusin <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
