From kde-core-devel Mon Feb 14 20:59:20 2005 From: Olivier Goffart Date: Mon, 14 Feb 2005 20:59:20 +0000 To: kde-core-devel Subject: Re: thoughts on the systray Message-Id: <200502142159.24399.ogoffart () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110841473612797 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1141271.pNOJIe4GLe" --nextPart1141271.pNOJIe4GLe Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le Lundi 14 F=C3=A9vrier 2005 21:00, Lubos Lunak a =C3=A9crit=C2=A0: > 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 taskba= r. 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. entri= es > 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=20 know what's the title of the music I'm listening to, or the Kopete tooltip = to=20 know what account are offline. Still about Kopete and Noatun, they icon change of state when we are playin= g=20 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= =20 from taskbar entry. =20 More, systray icons are on every desktop while takbar entry are only on=20 desktop the window is.=20 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 int= o=20 kicker. they also have a common "look" (a simple icon) Currents applets are all different, and they take generally more space on t= he=20 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 wha= t=20 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=20 notifications popups. Popups may show just nice without systray, if we have the icon of the=20 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 sin= ce > 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 everybo= dy > 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 ent= ry > (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 n= ew > 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= =20 add the possibility for applications to add actions in the popup. > 4) Daemons, quick access, whatever [...] > - Suggested fix: Stop using the systray for this.=20 Yes. =2D- Olivier --nextPart1141271.pNOJIe4GLe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCEREsz58lY8jWrL0RAmywAJ9VSIrDOXwBvTOOcT0o6jXsl20iPQCfbn/r aWpva9zOICLYNluBXF0wKao= =9jPY -----END PGP SIGNATURE----- --nextPart1141271.pNOJIe4GLe--