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.
>
> 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.
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?)
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...
>
> For some cases not providing our own function is not as annoying, take
> hostname, gethostname() should always query /proc.
>
>
sure, not so bad.
------------------------------------------------------------------------------
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
