On 08/08/13 18:48, Gustavo Sverzut Barbieri 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?
>
> 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.
>
>
Yeah, that's the thing. Just have the "things have changed" signals, and
let users query in the "proper way". Be it standard C/POSIX/EFL
abstractions doesn't matter. We just need to make sure to provide the
abstractions for things that are not standard.
--
Tom.
------------------------------------------------------------------------------
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
