[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    KNotificationAreaItem
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2009-04-20 18:11:38
Message-ID: 200904201211.39301.aseigo () kde ! org
[Download RAW message or body]


hi :)

there are several limitations inherent to the current xembed based system tray 
protocol, including:

* difficult to infeasible to embed onto a canvas, resulting in hacks for 
canvas based system tray hosts (plasma-desktop and e17, for two)

* relatively slow (the embedding process is often measured in the 100s of ms; 
you can watch them get added in plasma-desktop currently)

* the application will unnecessarily block all interaction due to things like 
a modal dialog; one of my favourites is when opening a torrent from a web 
browser in ktorrent, ktorrent will pop up a modal dialog asking where to put 
it and then the systray icon becomes completely unresponsive

* no information about the icon itself is available to the host beyond "hey 
look, there's an icon"

* no allowance for styling by the host; e.g. the icons loaded are done so by 
each application which can lead to a variety of styles in the same tray, but 
even worse those entries will not look or behave the same as the rest of the 
items on the panel (or, in the less common case, desktop). for plasma that 
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 
based on d-bus.

the way it works is this:

* there is a client side class (KNotificationAreaItem for KDE, though other 
toolkits would want to provide their own obviously :)

* there is the concept of a "visualization" that displays those items 
(whatever that means for the given visualization), retrieving the data as 
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 the 
visualizations (in the case of KDE, a kded4 module, though each environment 
could and should provide its own)

when a visualization registers with the daemon, the d-bus service activates a 
d-bus service for the items to use. when there are no visualizations, the 
service is not activated.

the client side class watches for this service and when it exists it uses it. 
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 
method be used. you can switch between them at runtime (easily tested by 
turning on/off the d-bus service manually and watching the entries in the 
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-based 
API to ease porting and preserve features. we realize that there will be 
several years of co-existence of these two methods even if things go 
swimmingly and projects start jumping on the train.

the important bits for non-KDE people look at are the d-bus interfaces in 
libknotificationareaitem.

we have the host implementation already there and working for KDE 4.3 and 
have, as a means to get testing going, ported a number of KDE applications to 
use KNotificationAreaItem. this has helped us to get things working according 
to the existing application expectations, though we do have one more item left 
on the agenda there 

(which is to handle middle mouse clicks; we don't want to expose it as a 
"middle mouse click" but semantically as a "secondary action activation"; 
we're still discussing how best to expose that through the API; comments 
welcome)

for KMix, which does a few interesting things with the tray (wheel events, 
tooltips, changing icon in response to events, a popup it positions itself on 
left click ..), was a +52 -68 line patch. it wasn't time consuming, most of 
its systray support code wasn't touched at all and it "just works" as expected 
(modulo the middle click mutes feature; perhaps that's a questionable feature 
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 
status, a system service or messaging? does it currently need attention from 
the user? is it currently just idling with nothing useful to say? this gives 
us the ability to do things like sensible autohiding (already implemented in 
the system tray plasmoid..)

* are able to view systray icons in multiple places (e.g. a systray on each 
screen in the case of mullti-screen set ups; ability to show some icons in the 
traditional tray area, but merge others with entries with window entries in 
the taskbar, or both simultaneously; push the messaging icons into their own 
special area, etc, etc)

* able to theme, display and provide interaction hooks that are contextually 
appropriate to the visualization rather than the application

* get a lot more speed on start up and seamless integration with canvas based 
apps


our intentions / hopes are:

* to port a number of KDE apps to the separate and non-BC guaranteed 
libknotificationareaitem library for 4.3 and ship libknotificationareaitem 
separate from libkdeui; we would like to have a full release cycle of 
application developer feedback and user experience where we can adjust the API 
as needed.

* to include KNotificationAreaItem in libkdeui for KDE 4.4, assuming all goes 
well in the 4.3 time frame

* publish a formal spec via fd.o describing this system in proper detail with 
the hope of having it adopted by other projects; in fact, we'd be very happy 
to work with other projects sooner than that even (gentlemen, start your 
feedback engines!)

* eat lots of delicious ice cream in the sun


the plasma team is taking responsibility for doing the initial porting work, 
passing the patches to the respective projects as we go (with whom the 
decision to commit or not lies), though that shouldn't stop anyone from 
porting their application on their own if they so desire :) 

if/when things move to libkdeui, we'll also go around and fix up the build 
system as needed.

questions, comments are desired.

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


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]