KNotificationAreaItem

[Aaron J. Seigo]

On Tuesday 14 April 2009, Marco Martin wrote:
> On Tuesday 14 April 2009, Aaron J. Seigo wrote:
> > 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...

yes...

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

another good example indeed ...

> or maybe the icon could constantly inform the app about its geometry when
> changes? this would remove x and y parameters from contextmenu too...

this would break with multiple visualizations and would cause a lot of traffic 
on the bus when moving the icons around (with the benefit of keeping shown 
popups "next to" the icons as they move)

> 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

hm.. true, that's what we already do in fact. still, we need geometry 
information available to do 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...

that makes sense, yes, though shouldn't it have a bool then for whether it was 
actually activated or not?

> > * 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?)

it could be, yes. but i think they should have to take specific steps to get 
that behaviour, rather than randomly end up there because they repopulate on 
aboutToShow() ;)

in any case, the standard items are only there if a parent widget is handed 
in. well, that's not entirely true: the quit action is currently hardcoded in 
there in KSystemTrayIcon.

we could come up with some nice way of handling this i suppose ...

-- 
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://mail.kde.org/pipermail/plasma-devel/attachments/20090414/3285dd3a/attachment.sig