From kde-core-devel Fri Apr 24 00:03:05 2009 From: "Aaron J. Seigo" Date: Fri, 24 Apr 2009 00:03:05 +0000 To: kde-core-devel Subject: Re: KNotificationAreaItem Message-Id: <200904231803.10802.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=124053147510763 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1892048.di5Nm07a9E" --nextPart1892048.di5Nm07a9E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday 23 April 2009, you wrote: > * There are function calls for both popup menu and mouse click. > And I guess I don't understand the difference. Would a someone > get both the mouse click event and a popup menu event if someone > clicked on the icon? only one of the three possible actions are triggered at a time.=20 or at least, you can treat it that way. there's nothing stopping an=20 implementation from calling Activate then ContextMenu then Activate in=20 succession. that would be silly and insane, but there's nothing saying you= =20 couldn't write such an implementation. and instead of thinking in terms of "mouse event", consider them as "action= =20 triggers" since there's nothing in the spec itself that says what leads up = to=20 them being triggered or what must be done when they are triggered. the actions describe in implementation neutral terms what triggers are pull= ed=20 and it's up to the actual implementations to decide how to trigger them and= =20 what precisely to do when triggered. there are three possible actions currently defined: * ContextMenu * Activate * SecondaryActivate in plasma: * right clicking triggers ContextMenu * left clicking triggers Activate * middle clicking triggers SecondaryActivate in libknotificationitem: * ContextMenu shows a popup menu * Activate shows the associated window (if any), though you can connect to = the=20 signal yourself and do something else * SecondaryActivate does nothing by default, though kmix for example uses i= t=20 to mute/unmute the channel this is probably the typical implementation we'll see in general, because i= t's=20 consistent with legacy tray behaviors. but it could just as easily be a voi= ce =20 driven system, a text interface or fluffy dancing bunnies pantomiming the=20 items. ;) this is why we put no definition beyond "here are the triggers". > * With the mouse click event I'm guessing that the x,y are the x,y > inside the icon? Or on the screen? screen > It seems like you'd need > the screen coordinates if you wanted to put a menu there, but if > you had a complex icon you'd want to know where in the icon was > clicked. you should never rely on this as it makes assumptions about how the=20 visualization is displaying the item.=20 now, i don't know of any systray icon that would require this now (do you k= now=20 of one?), and any that one might dream up i'd file under "broken, please wr= ite=20 a widget for your panel system" :) > * If it's the screen coords how do you know where your icon is? you don't need to. you don't even know if your icon is even visible. it mig= ht=20 not be. > Do we need to know a screen as well? the coords are global, so no. (e.g. for a screen that is right of a 1024x76= 8=20 screen, you wouldn't get anything less than (1025, 0); just like usual wind= ow=20 geometry) > * It seems like that by having the application draw the menu > you'll end up with GTK menus in the KDE panel and vice versa. yes; this was done because: a) a "pass the menu using xml" approach wouldn't cover things like "widgets= in=20 the menu" or apps that don't actually show a real menu but some other popup= =20 style interface; so we would still require a fallback for apps with such=20 oddities (iow: there was no avoiding it realistically) b) even with a menu-by-description method, the signal would still be needed= so=20 that applications populate the menu only when it is about to be shown (a va= lid=20 use case and a very common technique) could do so b) it means a LOT less porting effort in the immediate term, so we didn't p= lan=20 on using such a thing immediately longer term, if it becomes an issue we feel is worth solving, we can offer = a=20 menu-by-xml method without breaking anything else. if you'd like to work on such an addition to the spec, i'd happily accept i= t=20 as a valued addition. if you are interested, some thoughts/notes off the to= p=20 of my head: * i think there's something similar already used by gnome for their global= =20 menu bar? perhaps looking into that would be useful and re-use something fr= om=20 there as there's no point in reinventing wheels unnecessarily ... for those on the kde mailing list: * for the KDE case, we probably just want a void=20 setContextMenu(QList) that created the XML from those actions; no= te=20 that you'd need to monitor the actions using the signals they emit to chang= e=20 the xml when an action is enabled/disabled/deleted =2D-=20 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 Qt Software --nextPart1892048.di5Nm07a9E Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAknxAb4ACgkQ1rcusafx20Pa/QCgpQ/cAC7DFRVjmfzq4K+4gvbX TEAAoJsdMIljV6+g25U9zwLjH1d2EDmq =5iOY -----END PGP SIGNATURE----- --nextPart1892048.di5Nm07a9E--