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