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
