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. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel