On 10/08/2013, at 02:18, Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> 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. You can do it :) otherwise I can try to handle it on Monday. Also check the locale one, I've prefixed it with "system", see if you like it. > 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. :) My old MacBook also has ssd and running well for 2+ years... And that one did daily compile of stuff, this one was basically an "user machine" with all apps in macos, and a vm with arch + e17. So vey 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 > > > -- > ------------- 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 ------------------------------------------------------------------------------ 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
