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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
