another update on the systray and tiny api review

[Aaron J. Seigo]

On Wednesday 18 March 2009, Marco Martin wrote:
> -setMovie() we are on dbus now, sending the binary data is already
> expensive enough

well, for animations it probably makes sense to send all the frames across at 
once and then animate them on the host side. sending images constantly over 
dbus might suck badly. anyways ..  we won't get away from having animations on 
the system tray, so we may as well provide setMovie in the client side API and 
go the naive route for now (sending the frames across the bus one by one) and 
look into optimizing this later if needed.

> -geometry() a thing that is purposefully removed from the spec, i.e the app
> shouldn't know nothing about the real graphical representation

yes

> -icon/setIcon(): now there are two kinds, setIconName, the preferred way,
> in this case the real icon loading will be done by the systray with KIcon()
> and setIconPixmap

for the API, what about:

	setIcon(QString)
	setImage(const QImage)
	setImage(const QPixmap)

and just note that if setImage is called, it overrides whatever is passed to 
setIcon (if anything). if an empty/null image or pixmap is set, it can then 
fall back to the icon name again. that part sounds like a host-side issue, 
really.

> -loadIcon: made pretty much useless by setIconName

yep

> -setToolTip: it's a simple string, so has to be replaced with several
> functions  settooltiptitle/subtitle/icon

yes... perhaps the same style as the plasma tooltips?

> -parentWidgetTrayClose apart from the fact that i still didn't get exactly
> what the thing does is perhaps a thing a bit too specialized for the
> current systemtray implementation?

it probably isn't necessary anymore, no.

> -setContextMenuTitle: seems an implementation detail not really useful? the
> contextmenu is accessible anyways...

agreed..

> Things that i'm thinking about to implement:
> -parentWidget and actionCollection, again implementation details that i
> wonder if they are really useful

these are only needed for the fallback-to-the-fd.o-style case

> -showMessage a shortcut for knotify? does really belongs here? probably the
> pplication should just use knotify...

and if it's not a knotify or VisualNotificatons app? i think for backwards 
compatibility it makes sense to provide this. we can do whatever we want with 
it (e.g. forward it over the visual notifications service or whatever), but 
without this porting applications will be even harder. this is probably 
especially true of non-kde apps that may adopt this in the future.

> after defining those points i think ill rename the thing again to
> libknotificationicon and could be tought about moving the thing out of
> playground (for 4.3 still not to kdelibs? workspace or runtime for a
> limited testing perhaps?)

at least at first, yes ... once we can demo this thing in action then we can 
take it kde-core-devel and get some discussion on the matter there.

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

-------------- 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/20090320/342255f7/attachment.sig