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...
but sure, for these as I said we'd better have getters and setters.
Say you loaded a library that is battery or memory aware and we're in
"lowbat" or "lowmem" state, it should query and start in the proper
mode otherwise it wouldn't get the event.
>> 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.
>
> I'm wondering if it wouldn't be better to have locale stuff in efreet since
> it already exists there.
efreet? efreet just uses it so it can deliver the proper strings.
nothing more. You may have an app that is translatable but has no need
for efreet.
> for api in this case...tough call I guess. my thought here is that it may be
> more useful (and futureproof) to have the event just send out a bitmask of
> the changed locale flags and the user can check that to see if they're
> interested in what has actually changed. then we can keep adding flags as
> necessary without needing to copy/ref and free/unref things which aren't
> likely to be used (how often do people check lc_paper?)
in that sense I'd keep out of the flags. It's very rare to change one
field without changing the others. Also they seem to be the same, like
changing everything from en_US.UTF-8 to pt_BR.UTF-8. In some occasions
you do have LC_MESSAGES to be english while other fields to be in
Brazil's standard, but it is not common.
> I guess we'll likely need a getter for each of the locale types? having to
> remember/pass params seems convenient from a maintainer perspective, but it's
> not great to use since you have to remember the name of the function and the
> parameter string...
okay, but in that case the strings are the standard values supported
by all the other system. I wonder people end doing:
if (strcmp(wanted, "LC_CTYPE") == 0) value =
ecore_locale_lc_type_get(); else if ...
instead of value = ecore_locale_get(wanted)
also, in this case we could avoid creating these at all if we have the
ecore module to apply the values to applications automatically before
adding the event:
for (i = 0; i < n_fields; i++) setlocale(fields[i], values[i]);
ecore_event_add(ECORE_EVENT_LOCALE_CHANGED, NULL, NULL, NULL);
--
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
