thoughts on the systray

[Lubos Lunak]

On Monday 14 of February 2005 21:59, Olivier Goffart wrote:
> Le Lundi 14 Février 2005 21:00, Lubos Lunak a écrit :
...
> > - One more thing missing to be a good replacement for the current systray
> > way of doing this is the context menu, e.g. the play/stop/next etc.
> > entries for kscd/amarok. The idea is the application would simply
> > associate the actions with its main window, and the taskbar would provide
> > these actions in the popup. Since this is out-of-process, it's not
> > possible to simply provide a QPopupMenu and give it to the taskbar
> > (Aaron's proposal can't do this either as far as I can say). But the app
> > can give the taskbar a list of the entries, and the taskbar can built the
> > popup, and tell the app some entry was activated. No big deal with the
> > usual text menu entries, if needed even some more weird menu entry types
> > like sliders could be supported.
> >  This could be used for any app, even the ones with normal taskbar
> > entries of course. Think e.g. right-clicking on the KMail taskbar entry
> > and selecting 'Check mail' without switching to KMail before.
>
> There is also a need of a custom tooltip: I use often the tooltip of Noatun
> to know what's the title of the music I'm listening to, or the Kopete
> tooltip to know what account are offline.

 I guess simply the caption could be used that way. The taskbar already has a 
support for showing tooltips for such things. Alternatively, there's also the 
possibility to specify explicitly text different from the caption for the 
taskbar entry, although KDE doesn't really use it because when I was playing 
with it it was causing weird effects. It could get sorted out or something 
like that could get added if needed though.

> Still about Kopete and Noatun, they icon change of state when we are
> playing music or away in Kopete.
> Do you think it's a good idea to change the icon of the taskbar entry ?

 Yes, why not?

>
> The menu + the status icon + the tooltip make actual systray icon different
> from taskbar entry.
> More, systray icons are on every desktop while takbar entry are only on
> desktop the window is.

 I know this. That's why I said this special part of the taskbar could be 
actually a separate applet, i.e. there'd be the "normal" taskbar and then 
there'd be the "systray" taskbar. There'd still be the other advantages of 
doing it the taskbar way instead of the current systray way.

>
> Or maybe do you consider that as "applet" ?
>
> > 2) applet-like cases
> > - Suggested fix: Stop using the systray for it, convert them to applets.
> > Assuming Kicker's handling of the applet geometries improves a bit, one
> > will be able to position applets much better in Kicker than systray
> > icons. Another part is creating a spec that'd be shared with GNOME.
>
> Systray icons are nice, because they are all 22^2 pixels, they fit good
> into kicker.  they also have a common "look" (a simple icon)
>
> Currents applets are all different, and they take generally more space on
> the kicker.

 There's no reason kicker applets couldn't do what systray icons can. That's 
what I meant with KPixmapPanelApplet.

>
> [...]
>
> > - One additional problem here is that the content of the applet window is
> > completely controlled by the applet. This is definitely necessary for
> > some applets, e.g. for the kmix applet (applet, not the systray kmix).
> > But for many the functionality along the lines of 'show this pixmap' and
> > 'show context menu', like in Aaron's proposal, is enough. I think this
> > could be simply handled by subclassing KPixmapPanelApplet from
> > KPanelApplet, which would solve Aaron's objections to applets.
>
> Good idea, and group them nicely in the kicker.  Oh, but that's exactly
> what the systray do.

 Hmm. Do you know the answer for the Klipper systray vs Klipper applet 
question in my previous mail? Just like in the taskbar case, even if it looks 
about the same, there are still advantages in dumping the current systray. 
It's redundant, if nothing else (and there are several else's).

 And BTW I don't see any special reason why applets would have to be grouped 
in the kicker.

>
> > 3) Notification
>
> You haven't said example.
> You are talking about passives popups notifications ?

 No. I mean two cases, one being that that the app's systray icon simply 
starts blinking or whatever. The second is the case when a new systray icon 
gets added when a new event occurs. I think this is common in Windows. 
Basically it's what I described as the new notification area.

>
> In fact, there is absolutely no need to have a systray icon to show
> notifications popups.
> Popups may show just nice without systray, if we have the icon of the
> application in it to let the user from what application the pop up is
>
> > - I'd like to point out here that it's such a shame we've had KNotify
> > since ages, offering so many possibilities for notifications and related
> > features, and nobody has touched it since a long time ago. Pretty much
> > everybody these days rolls their own notification stuff, in systray,
> > using passive popup, whatever. If KNotify got some additional care, and
> > everybody did just KNotifyClient::event("whatever"), we could simply have
> > consistent notifications, consistent configuration for it, and new
> > features for every app  - for example, history of events, queueing of
> > events, profiles (busy/silent/whatever).
> >
> > - Suggested fix: Ok, first of all, I don't intend to do anything about
> > this. But if I happened to have a lot of spare time and felt an urge to
> > do so, I'd try the following: KNotify gets features that prevent some
> > apps from using it, for example feedback for events (so that e.g. Kopete
> > can dump its own KNotify fork which has buttons with actions in
> > notifications about events). It could get also the features I listed
> > above. Apps would use KNotify only, and it would take care of it. I
> > wouldn't really care if apps notified about events using passive popups,
> > blinking the taskbar entry (which with the new taskbar "systray" would be
> > basically like it's now), or by queueing systray icons (i.e. some apps
> > notify about event by placing new icons in the systray, and clicking it
> > opens new window with details about it - it would be preferably a
> > separate kicker applet, a real notification area).
>
> I would like to improve KNotify a lot for KDE4.
> Letting application to have control of the notification if they wishes. And
> add the possibility for applications to add actions in the popup.

 That'd be great.

-- 
 Lubos Lunak
 KDE Developer