head's up that this is in git right now.
On Fri, Aug 9, 2013 at 6:12 AM, Tom Hacohen <tom.haco...@samsung.com> wrote:
> 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
--
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
