On Sat, 10 Aug 2013 00:48:24 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> Q comments: > > The state is low mem/bat, but it means a change happened. You should use > getter to figure out the on/off. Can change the name, but I'm not too found > of a multiple level... People barely handle two and I guess more complex > decisions should be done elsewhere, like the wm changing ionice/nice/oomadj > more aggressively on various levels. the wm can't stop the app from polling some url every 5 seconds over an lte radio that's sucking juice... :) i don't think people HAVE to handle all levels, but if its an enaum they can choose which levels they handle and we logcially can only be in one state at a time. also getting a low battery (or low mem) event to tell you you are NOT in that state anymore sounds odd... so a name change might be best either way P) > As for commit, I didn't have my keys, lost my ssd but sent a new key via > Tasn. All fixed oooh crap! that sucks. :( hope you're all back to normal. how did you lose the ssd? > --Gustavo > > Sent from my iPhone > > On 10/08/2013, at 00:13, Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Fri, 9 Aug 2013 01:10:09 -0300 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > > comments inline... > > > >> Hey, > >> > >> find the patches attached, they implement what I said. Also attached > >> is a small test app to print out the values when they change. One can > >> change it with: > >> > >> localectl set-locale LC_MESSAGES=en_US LC_CTYPE=pt_BR > >> timedatectl set-timezone America/Sao_Paulo > >> sudo date --set="00:00:00" > >> hostnamectl set-hostname "something" > >> > >> all of these should generate the events if you're running with > >> systemd. If you're not, then the "sudo date" should work given that > >> you have timerfd. > > > > cool. i was going to mention the date change thing can be done via timerfd > > on linux :) > > > >> What do you think? (If you like could you commit, I'm out of commit access) > > > > you don't have commit access? eh? of course you do! :) or you mean you can't > > commit right now due to network or whatever issues? > > > > my comment is on low mem/batttery events. as per my other mails. i think > > these are better renamed POWER_STATE and MEMORY_STATE ... along with all > > the getters and setters - make power state an enum and memory state too. :) > > memory state for now can just be NORMAL and LOW for memory we can add more > > enums/state later if we want. :) > > > >> On Thu, Aug 8, 2013 at 3:24 PM, Gustavo Sverzut Barbieri > >> <barbi...@profusion.mobi> wrote: > >>> 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 > >> > >> > >> > >> -- > >> Gustavo Sverzut Barbieri > >> http://profusion.mobi embedded systems > >> -------------------------------------- > >> MSN: barbi...@gmail.com > >> Skype: gsbarbieri > >> Mobile: +55 (19) 9225-2202 > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > -- ------------- 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
