On Friday 19 March 2010, Sebastian Kügler wrote: > On Friday 19 March 2010 17:21:37 Aaron J. Seigo wrote: > > On March 18, 2010, Rob Hasselbaum wrote: > > > On Thu, Mar 18, 2010 at 11:04 AM, Marco Martin <notm...@gmail.com> wrote: > > > > what are you exactly trying to accomplish? > > > > thanks for asking the Right Question(tm) :) > > > > > > usually you shouldn't care of a detail like that > > > > > > I have a data engine that pushes data to my applet asynchronously. When > > > the applet isn't being shown, I want to disconnect from the source to > > > reduce CPU overhead. > > > > i can think of various hacks to accomplish this, but they aren't > > particularly pretty and i only know they'll work because i know how > > things work internally (which is never a good sign for a "solution" ;) > > > > i think the only clean solution to this would be to offer a bool > > PopupApplet::isIconified() const method. > > > > btw, i sat here for a few minutes trying to discount your use case, but > > it is a valid one imho. if it is't being shown to the user, the applet > > should at least have a chance of not waking up the cpu. > > > > my only question now is how to handle notification of the change. my > > first thought would be to add a new Contraint (IconifiedConstraint?) and > > then the applet could respond in constraintsEvent. > > It's not only about being iconified, the applet could also be one a > containment that's not shown, or on the dashboard (separate from the > desktop background and invisible). > > I wonder if we could just offer queueing updates from dataengines until an > applet is about to be shown. Especially for mobile devices, this "not > waking up unless shown" can be very important.
yes, i think it should be generalized to catch those cases as well. also to be careful to not make it too rigid since we could want updates in a popupapplet too if the icon or the widget that replaces the icon is dependant from the data of the dataengine (clock, microblog, weather...) so, cases could be: -closed popupapplet -containment without screen() -separate dashboard (even worse, that is a containment that is never assciated to a screen, but someties shown) the way that would be killer would be to actually know if a given widget is shown by at least one view (that is in this moment actually visible) or not, but i don't think there a re -efficient- ways to do that Cheers, Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
