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.
As for commit, I didn't have my keys, lost my ssd but sent a new key via Tasn. All fixed --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 > ------------------------------------------------------------------------------ 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
