On 10/08/2013, at 00:54, Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> 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) Suggestion? >> 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? My 2 months old MacBook Air died, no idea why... Bad luck > >> --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
