another update on the systray and tiny api review

[Marco Martin]

On Friday 20 March 2009, Aaron J. Seigo wrote:
> 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.

did some experiments on that, sending a qvector of the frame images seems 
quite easy, the problem seems recontruncting a qmovie from that on the other 
side.
QMovie seems just a class that reads files (or a custom QIODevice that 
produces exactly the bytes that could be found in a mng or animated gif)
so, transferring the movie data seems so complicate (and also unlikely that 
client applications will build one not starting from a file) that it seems to 
make more sense just to send the filename..

and this rises an interesting issue: movies or blinking icons are usually used 
for notificatins. now the systray has a "notifying" state that for now the 
applet doesn't really uses (it tries to put the icon in the last position like 
the notification popup ones, but fails and not sure if it makes sense)

what the systray should do when the state is notifying? a sane thing i think 
it is:
add a new icon for the requesting attention case and it will blink between the 
two, or if a movie is set it displayis the movie, that is passed just as 
filename, however.

Cheers,
Marco Martin

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