KNotificationAreaItem

[Marco Martin]

On Tuesday 14 April 2009, Aaron J. Seigo wrote:

> > 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)
aaw, true :)

sooo, now i did the Activate slot with a position as parameter 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
>
> 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?

now has a bool+position

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