On Sat, 10 Aug 2013 01:15:00 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> > 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? 1. change low mem and low battery events to POWER and MEMORY events, make returns from these funcs return enums. do you just want me to do my suggestion in git? you can revert it? or send a patch? > > >> 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 major poo. :( my s9 is still humming along 1.5years later or so... ssd and all. :) > >> --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 > > > -- ------------- 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
