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.

oouch..
i can try if an array of the struct i did to serialize qimages would be 
enough, let's see if it will have success (/me learning to never ever say "how 
hard can it be" when talking about dbus:p)

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

looks sensible, won't be still 100% compatible with the old api, but i like it

>
> 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?
yes, i have settooltipTitle setTooltipSubtitle and settooltipIcon (also here 
icon name or pixmap) to fill the plasma tooltip fields, so not the old 
settooltip
could be also a single struct parameter that basically clones 
plasma::tooltipdata, but would lose the ability to set directly graphics for 
it

> > -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
well, i still have a popup menu with an actioncollection and a parent widget 
to show/hide on activate, so would be roughly the same

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

> > 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.
yeah we can start with some tiny kdebase stuff, like klipper and keyboard 
layout thinghie..