more on the systemtray

[Aaron J. Seigo]

On Saturday 28 March 2009, Marco Martin wrote:
> now the services are called org.kde.SystemTray and
> org.kde.systemTrayDaemon, since the client is called KNotificationIcon, i
> think the services would make more sense as
> org.kde.NotificationIcon and org.kde.NotificationIconWatcher
> straightforward but would require a quite massive renaming of stuff...

so .. just to screw things up completely (that's what i do, right? ;), i've 
been chaffing at the term "icon" since that may or may not at all be what 
happens. and i dislike "system tray" as well. now .. our "friends" in redmond 
(and GNOME?) apparently call this the "notification area" and tbh that's 
really not such a bad name.

how about ...

org.kde.NotificationAreaWatcher and org.kde.NotificationAreaEntry?

eventually, should our hopes and dreams come true ;), this would see one more 
rename from org.kde.* to org.freedesktop.*

> also, since usually the dbus exposed functions and methids are uppercase,
> should i do so also there?

probably ... bleh.

> images passing:
> still didn't understood what should be the better way to pass images over
> dbus, now it passes the PNG data, and this is probably the most portable
> way, but also really slow (it has to compress /uncompress the image every
> time) another way could be to pass the raw pixel data, that would take dbus
> for a bit longer but faster to write/load, it would need additional info
> (the overkill galago data or just width, height, data and assume that is
> always argb32)

have you done any measuring of these two approaches? boring work, but it would 
be interesting to see what sort of throughput we get for 22x22, 32x32 and 
256x256 pixmaps as PNGs or raw data. the raw data might be nicer for apps that 
don't have png capabilities in their toolkits, assuming it's fast enough.

> another way could be as fredrik suggested me today, just pass x11 pixmaps
> handles, no copy, really fast, but portability issues?

yeah, i think the portability issues sort of kill that. these aren't huge 
chunks of data, really.

-- 
Aaron J. Seigo, today's spoilsport
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090330/187e6ccb/attachment.sig