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.
> 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.
valid point
>
>
> > 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, you're more of an expert than I am since I'm a native speaker
>
>
> > 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)
I suspect this is going to be a per-application usage thing, so whatever we
choose will be good and bad here
>
> 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);
>
>
------------------------------------------------------------------------------
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
