On Thu, Aug 8, 2013 at 3:18 PM, Michael Blumenkrantz <michael.blumenkra...@gmail.com> wrote: > On Thu, 8 Aug 2013 15:13:01 -0300 > Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > >> On Thu, Aug 8, 2013 at 3:01 PM, Michael Blumenkrantz >> <michael.blumenkra...@gmail.com> wrote: >> > On Thu, 8 Aug 2013 14:48:54 -0300 >> > Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: >> > >> >> On Thu, Aug 8, 2013 at 2:31 PM, Michael Blumenkrantz >> >> <michael.blumenkra...@gmail.com> wrote: >> >> > On Thu, 08 Aug 2013 17:16:40 +0100 >> >> > Tom Hacohen <tom.haco...@samsung.com> wrote: >> >> > >> >> >> I like almost all of the suggestions. Apps need the information so they >> >> >> can assist the system to behave better. >> >> >> >> >> >> One thing I don't like is the passing of information through the >> >> >> signals. I think we just provide the notification and let the user >> >> >> probe >> >> >> for whatever it needs. I don't like creating additional structures that >> >> >> we'll have to maintain. Also, if an application cares about a certain >> >> >> feature it usually already has code that probes for it and acts upon it >> >> >> (when the application runs), having another way (the parameters passed >> >> >> here) will lead to code duplication. That's the thing I hated the most >> >> >> when working on SHR, having signals and getters with different >> >> >> signatures so you had to write glue code everywhere. >> >> >> >> [..] >> >> >> >> > >> >> > I have to reluctantly agree with Tom on this. The idea of having even >> >> > more event structs to remember is not something that I would enjoy >> >> > thinking about, let alone using. >> >> > >> >> > Everything else sounds like a great (and long overdue) idea, however. >> >> >> >> >> >> okay, so provide getters and setters (would add the event >> >> automatically) but the signal itself shouldn't carry any information? >> >> Not even the LOW battery/memory? >> > >> > I'm thinking that in most cases, we'll just want to send a "low battery" >> > or "low memory" event, no? imo this is what will be useful in most cases. >> > I'm not against having any event structs for new event types, I just think >> > we should be a bit more conservative than we have previously been. If we >> > have a "battery level changed" event, for example, then it makes sense to >> > include the %battery, but if it's "low battery" then it doesn't. >> >> how do you say you're out of "low battery" state? Create 2 events? >> Cumbersome... > > you send the event at a certain percentage of the battery, so you'll get it > when going into low battery and out. assuming you also get percentage events, > it should be pretty easy to track. failing that, the user can always just > check whether the battery is currently charging when that event is received.
actually you could listen to upower's http://upower.freedesktop.org/docs/UPower.html#UPower:OnLowBattery without checking individual battery levels for each present battery. It's automatic, the "low threshold" is configured in a system-wide way by UPower, it requires less bandwidth as updates are less frequent and easier to use. For tizen, they use vconf and a single key to indicate low-battery or low memory. (sure, strange they use a configuration system to propagate that state change). thus I don't think the levels should be handled or expected in here. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
