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

Reply via email to