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

Reply via email to