KNotificationAreaItem

[Marco Martin]

On Tuesday 14 April 2009, Aaron J. Seigo wrote:
> hi..
>
> this evening i ported KMix to use KNotificationAreaItem. it was very easy
> and it still works ;)
>
> there are a few caveats:
>
> * Activate has not positioning information
>
> kmix tries to position the parentWindow (that borderless window with a
> slider and the Mixer button) to match up with the icon, as if it were a
> popup associated with it. we don't pass any geometry information back with
> the Activate() dbus call as we do with ContextMenu(int,int).
>
> the questions i have are:
>
> a) what to send across to help make this happen: x and y? a rect, emulating
> geometry()? a Direction? it would be nice is such popups could decide to
> center on the icon and even more so if they could appear outside of, e.g.,
> panels; e.g. essentially the same thing as Corona::popupPosition does.
>
> b) should a setHandleParentAsPopup(bool) method, which would internalize
> this behaviour and all it's intricacies? this way there could also be two
> code paths: one for the legacy mode and one for the new mode
position would have to be passed anyways tough...
>
> c) is there someway to avoid having to support this at all? ;) kmix is
> using it rather .. uhm .. creatively. but it seems like a valid use case in
> that situation.
klipper too, where left and right mouse buttons do the same thing

or maybe the icon could constantly inform the app about its geometry when 
changes? this would remove x and y parameters from contextmenu too...
maybe the default impl will take it into account for context menu and not for 
activate, if for activate is rare enough it could be subclassed in application 
that need it
>
>
> * activateRequested() signal - unused?
>
> the activateRequested() signal doesn't seem to be used; is there a purpose
> for it?
aaaw, could be a piece i forgotten, was to give the application a way to know 
when the user activated the icon clicking on it (useful? not?), thinking about 
it could be avoided reimplementing the show event in the main widget...
>
>
> * context menu handling
>
> when using KSystemTrayIcon there are some additional items added (activate,
> quit). thinking about how to handle this, we could either do exactly what
> KSystemtrayIcon does when in "new and improved" mode and add these items
> after aboutToShow is called the first time or we could improve on this
> somewhat ;)
>
> the thing with KSystemTrayIcon is that if you clear the menu after it's
> shown once, you won't get those actions in the menu anymore. nobody does
> this it seems, however., so that's all good so far. so maybe this is Good
> Enough(tm)
>
> however, we could do thing a few different ways:
>
> - provide a KActionCollection to register actions with, and then when the
> menu shows clear it and populate it with the context of the action
> collection plus our own
couldn't be that apps could -not- want the default actions (no quit action 
sounds nasty hmm, but could even make sense for system stuff?)
>
> - provide an addAction / removeAction pair that would do more or less the
> same thing internally
>
>
> * Tooltip -> ToolTip for consistency with the rest of the Qt/KDE api
> (already changed and commmitted to svn)
oh, thanks :)


Cheers,
Marco Martin