more on the systemtray

[Marco Martin]

On Monday 30 March 2009, Aaron J. Seigo wrote:
> 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?

yes, it makes sense,
so i think i'll use it also for the class name of the client library, next 
days will be a triumph of svn mv yee :)

> eventually, should our hopes and dreams come true ;), this would see one
> more rename from org.kde.* to org.freedesktop.*
yeah, but should be done only after, right? having it steal a namespace 
wouldn't be so nice :p

> > 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.
eh, nope, and i was hesitant since i know how easy is to do benchmarks that 
are totally bullshit :p
can try, at least to have a rough idea

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