On Sat, 10 Aug 2013 12:09:29 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Thu, 8 Aug 2013 15:24:48 -0300 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > > > 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. > > i agree. "low power" would be some system configured battery state > when the "system" believe we are low on power. we just need the > reverse - to tell apps everything is normal again power-wise. we > probably need "ac plugged/unplugged" event too. so effectively power > would have 3 states "full power - feel free to do whatever you like > and not care about power", "normal power - be a bit careful and > realize doing things will impact battery life" and "low power - cut > out everything non-essential". simple and covers the 3 common cases > we see in laptops, phones, tablets, etc. all the time. again - i > don't see a problem with structs delivering the info, and it can be > very useful, but i agree, getters are also useful. Wouldn't "AC plugged in" and "low power" be the only ones needed? Power levels only go up while AC is plugged in, and if there's not enough juice in the battery when it's unplugged, it would go straight to "low power". So "normal power" can be inferred. Though that's really the difference between three states and two bits. Just woke up, excuse the brain fart. /me gets brekky and caffeine. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
