KNotificationAreaItem

[Aaron J. Seigo]

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. 

or at least, you can treat it that way. there's nothing stopping an 
implementation from calling Activate then ContextMenu then Activate in 
succession. that would be silly and insane, but there's nothing saying you 
couldn't write such an implementation.

and instead of thinking in terms of "mouse event", consider them as "action 
triggers" since there's nothing in the spec itself that says what leads up to 
them being triggered or what must be done when they are triggered.

the actions describe in implementation neutral terms what triggers are pulled 
and it's up to the actual implementations to decide how to trigger them and 
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 
signal yourself and do something else
* SecondaryActivate does nothing by default, though kmix for example uses it 
to mute/unmute the channel

this is probably the typical implementation we'll see in general, because it's 
consistent with legacy tray behaviors. but it could just as easily be a voice  
driven system, a text interface or fluffy dancing bunnies pantomiming the 
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 
visualization is displaying the item. 

now, i don't know of any systray icon that would require this now (do you know 
of one?), and any that one might dream up i'd file under "broken, please write 
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 might 
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 1024x768 
screen, you wouldn't get anything less than (1025, 0); just like usual window 
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 
the menu" or apps that don't actually show a real menu but some other popup 
style interface; so we would still require a fallback for apps with such 
oddities (iow: there was no avoiding it realistically)

b) even with a menu-by-description method, the signal would still be needed so 
that applications populate the menu only when it is about to be shown (a valid 
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 plan 
on using such a thing immediately

longer term, if it becomes an issue we feel is worth solving, we can offer a 
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 it 
as a valued addition. if you are interested, some thoughts/notes off the top 
of my head:

* i think there's something similar already used by gnome for their global 
menu bar? perhaps looking into that would be useful and re-use something from 
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 
setContextMenu(QList<QAction*>) that created the XML from those actions; note 
that you'd need to monitor the actions using the signals they emit to change 
the xml when an action is enabled/disabled/deleted

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090423/a2a549d7/attachment.pgp