From kde-core-devel Mon Apr 20 18:11:38 2009 From: "Aaron J. Seigo" Date: Mon, 20 Apr 2009 18:11:38 +0000 To: kde-core-devel Subject: KNotificationAreaItem Message-Id: <200904201211.39301.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=124025116527240 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart6671889.dBVNk8Z3pi" --nextPart6671889.dBVNk8Z3pi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi :) there are several limitations inherent to the current xembed based system t= ray=20 protocol, including: * difficult to infeasible to embed onto a canvas, resulting in hacks for=20 canvas based system tray hosts (plasma-desktop and e17, for two) * relatively slow (the embedding process is often measured in the 100s of m= s;=20 you can watch them get added in plasma-desktop currently) * the application will unnecessarily block all interaction due to things li= ke=20 a modal dialog; one of my favourites is when opening a torrent from a web=20 browser in ktorrent, ktorrent will pop up a modal dialog asking where to pu= t=20 it and then the systray icon becomes completely unresponsive * no information about the icon itself is available to the host beyond "hey= =20 look, there's an icon" * no allowance for styling by the host; e.g. the icons loaded are done so b= y=20 each application which can lead to a variety of styles in the same tray, bu= t=20 even worse those entries will not look or behave the same as the rest of th= e=20 items on the panel (or, in the less common case, desktop). for plasma that= =20 means tooltips, icon hover/press effects, etc, etc * only one visualization at a time the plasma team have been working on a new approach to the system tray, one= =20 based on d-bus. the way it works is this: * there is a client side class (KNotificationAreaItem for KDE, though other= =20 toolkits would want to provide their own obviously :) * there is the concept of a "visualization" that displays those items=20 (whatever that means for the given visualization), retrieving the data as=20 needed from them over d-bus and handling (most) interaction issues * there is a long-running d-bus service that keeps track of the items and t= he=20 visualizations (in the case of KDE, a kded4 module, though each environment= =20 could and should provide its own) when a visualization registers with the daemon, the d-bus service activates= a=20 d-bus service for the items to use. when there are no visualizations, the=20 service is not activated. the client side class watches for this service and when it exists it uses i= t.=20 when it doesn't exist, it falls back to the traditional xembed method. this way if and only if there is a new-fangled d-bus driven tray will that= =20 method be used. you can switch between them at runtime (easily tested by=20 turning on/off the d-bus service manually and watching the entries in the=20 system tray switch modes) the current client side KDE implementation can be found here: http://websvn.kde.org/trunk/playground/base/plasma/libknotificationareaitem/ the daemon plugin here: http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/systemtray= /notificationareawatcher/ and the host side here: http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/systemtray= /protocols/dbussystemtray/ the API of KNotificationAreaItem was kept as close to the current xembed-ba= sed=20 API to ease porting and preserve features. we realize that there will be=20 several years of co-existence of these two methods even if things go=20 swimmingly and projects start jumping on the train. the important bits for non-KDE people look at are the d-bus interfaces in=20 libknotificationareaitem. we have the host implementation already there and working for KDE 4.3 and=20 have, as a means to get testing going, ported a number of KDE applications = to=20 use KNotificationAreaItem. this has helped us to get things working accordi= ng=20 to the existing application expectations, though we do have one more item l= eft=20 on the agenda there=20 (which is to handle middle mouse clicks; we don't want to expose it as a=20 "middle mouse click" but semantically as a "secondary action activation";=20 we're still discussing how best to expose that through the API; comments=20 welcome) for KMix, which does a few interesting things with the tray (wheel events,= =20 tooltips, changing icon in response to events, a popup it positions itself = on=20 left click ..), was a +52 -68 line patch. it wasn't time consuming, most of= =20 its systray support code wasn't touched at all and it "just works" as expec= ted=20 (modulo the middle click mutes feature; perhaps that's a questionable featu= re=20 though ;) the end result is that with this new mechanism we: * don't lose backwards compat with the fd.o xembed spec * get a lot more information on the icon: is it related to hardware, app=20 status, a system service or messaging? does it currently need attention fro= m=20 the user? is it currently just idling with nothing useful to say? this give= s=20 us the ability to do things like sensible autohiding (already implemented i= n=20 the system tray plasmoid..) * are able to view systray icons in multiple places (e.g. a systray on each= =20 screen in the case of mullti-screen set ups; ability to show some icons in = the=20 traditional tray area, but merge others with entries with window entries in= =20 the taskbar, or both simultaneously; push the messaging icons into their ow= n=20 special area, etc, etc) * able to theme, display and provide interaction hooks that are contextuall= y=20 appropriate to the visualization rather than the application * get a lot more speed on start up and seamless integration with canvas bas= ed=20 apps our intentions / hopes are: * to port a number of KDE apps to the separate and non-BC guaranteed=20 libknotificationareaitem library for 4.3 and ship libknotificationareaitem= =20 separate from libkdeui; we would like to have a full release cycle of=20 application developer feedback and user experience where we can adjust the = API=20 as needed. * to include KNotificationAreaItem in libkdeui for KDE 4.4, assuming all go= es=20 well in the 4.3 time frame * publish a formal spec via fd.o describing this system in proper detail wi= th=20 the hope of having it adopted by other projects; in fact, we'd be very happ= y=20 to work with other projects sooner than that even (gentlemen, start your=20 feedback engines!) * eat lots of delicious ice cream in the sun the plasma team is taking responsibility for doing the initial porting work= ,=20 passing the patches to the respective projects as we go (with whom the=20 decision to commit or not lies), though that shouldn't stop anyone from=20 porting their application on their own if they so desire :)=20 if/when things move to libkdeui, we'll also go around and fix up the build= =20 system as needed. questions, comments are desired. =2D-=20 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 --nextPart6671889.dBVNk8Z3pi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAknsutsACgkQ1rcusafx20PqMgCZATP7bkK9GS7CC/ISLASllVp/ WOwAnRlYsmEv5ybrUUUbGwbBVSlXfOhH =FyPc -----END PGP SIGNATURE----- --nextPart6671889.dBVNk8Z3pi--