thoughts on the systray

[Olivier Goffart]

Le Lundi 14 Février 2005 21:00, Lubos Lunak a écrit :
> 1) minimalization
>   - e.g. kscd, amarok, ksirc and similar - The basic intent is apparently
> to save space from the taskbar. [...]

>  - Suggested fix: Stop using the systray for this, and improve the taskbar.

Great idea.

[...]
> - 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.

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 ?

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. 

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.

[...]
> - 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.


> 3) Notification

You haven't said example.
You are talking about passives popups notifications ?

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.

> 4) Daemons, quick access, whatever
[...]

> - Suggested fix: Stop using the systray for this. 

Yes.


--
Olivier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050214/b98cc15b/attachment.sig>