On Thu, 8 Aug 2013 14:48:54 -0300 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
> 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?
given a low memory/battery event, the issue now is.. we have a one-way
transition. from "normal" to "low". how do we transition back? when battery is
now charged enough? memory is freed up? i am thinking this needs to be more of
a "POWER_STATE" notification, and "MEMORY_STATE". we CAN ship event structs
with it. it's handy to know WHAT changed for that event. the struct tells you
which thing caused the event. if you ONLY have getters and setters then you
have to figure it out yourself by knowing the PREVIOUS state before the event
was generated. in the end i see the POWER_STATE event being overloaded to not
just tell you about low battery, but tell you about ac pulg/unplug (you could
use cheaper/simpler animations or poll the network less if not on AC). you
could use it to tell programs to "sleep more" voluntarily. so i'd say have both
structs AND getters.
> On the getters/setters, any preference for things with multiple values
> such as locale? We can have dozen of LC_*, we could add one per item
> (ecore_locale_get_lc_all(), ecore_locale_get_lc_ctype()...), we could
> add one with extra parameter (ecore_locale_get("LC_ALL")) or we could
> even do not do any of those and rely on user querying it in another
> way (setlocale("LC_ALL", NULL) == query) but only valid for current
> process and existing values, if set in a configuration daemon it
> wouldn't change -- unless we do change ourselves before adding the
> event.
>
> For some cases not providing our own function is not as annoying, take
> hostname, gethostname() should always query /proc.
agreed. we likely have to provide our own.
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> ------------------------------------------------------------------------------
> 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
>
--
------------- 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
