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.
>
> --
> Tom.
>
> On 08/08/13 17:04, Gustavo Sverzut Barbieri wrote:
> > Hi all,
> >
> > Ecore provides some main loop events for system signals such as TERM,
> > QUIT, SIGUSR... however these are not all the system signals we have
> > or need. I want to propose the addition of the following events to
> > ecore.
> >
> > However since these signals are not a single standard as existing UNIX
> > signal, we'll need different implementations depending on the
> > platform/distribution. For instance systemd provides couple of them,
> > but not every system uses systemd. Others may be provided by Tizen or
> > UPower... To solve that problem I also propose to create ecore system
> > modules as .so, these will be dynamically loaded from a folder using
> > the traditional eina_module way.
> >
> > Before going into the signals: should we provide getters for those?
> > Eventually setters, so the modules would set the value, that would
> > emit an event and remember the value that could be later retrieved.
> > Use case would be loading something after the signal was dispatched,
> > so it would be missed and would assume regular state (not lowmem,
> > etc).
> >
> > Signals:
> >
> > ECORE_EVENT_LOW_BATTERY { Eina_Bool status:1; /* true = low, false = normal
> > */}
> >
> > Generated when battery is running out, above a threshold. Could be
> > generated by E17 battery applet, UPower
> > (http://upower.freedesktop.org/docs/UPower.html), Tizen (vconf), etc.
> >
> > Applications could throttle timers a bit, eventually elementary could
> > increase ecore/edje animator frametime...
> >
> >
> > #######################################
> >
> > ECORE_EVENT_LOW_MEMORY { Eina_Bool status:1; /* true = low, false = normal
> > */}
> >
> > Generated when memory is running out, above a threshold. Could be
> > generated by E17 or something else that polls /proc/meminfo. Tizen
> > (vconf), etc.
> >
> > Applications could flush caches, purge some data. Elementary could
> > flush its caches.
> >
> > #######################################
> >
> >
> > ECORE_EVENT_LOCALE_CHANGED {
> > const char *lang;
> > const char *lc_all;
> > const char *lc_ctype;
> > const char *lc_numeric;
> > const char *lc_time;
> > const char *lc_collate;
> > const char *lc_monetary;
> > const char *lc_messages;
> > const char *lc_paper;
> > const char *lc_name;
> > const char *lc_address;
> > const char *lc_telephone;
> > const char *lc_measurement;
> > const char *lc_identification;
> > }
> >
> > Not sure if all fields are required or should be provided, but
> > provides a hint when locale changed by user, such as in changing in
> > e17 or some other configuration tool.
> >
> > Could be implemented by monitoring /etc/locale.conf or using
> > http://www.freedesktop.org/wiki/Software/systemd/localed/. Tizen
> > provides something like this as well using vconf.
> >
> > For this one we could have a signal handler that calls setenv()
> > automatically, elementary could listen and update gettext and call the
> > language changed callback.
> >
> > #######################################
> >
> >
> > ECORE_EVENT_HOSTNAME_CHANGED {
> > const char *hostname;
> > }
> >
> > This may be used to update information and even status (tools that
> > authenticate based on name, such as xauth). Recent Linux kernels will
> > allow polling /proc/sys/kernel/hostname, but it could also be
> > monitored using
> > http://www.freedesktop.org/wiki/Software/systemd/hostnamed/
> >
> > #######################################
> >
> >
> > ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED
> > const char *timezone;
> > Eina_Bool local_rtc:1;
> > Eina_Bool ntp:1;
> > };
> >
> > Called when system time configuration changed. Could be based on
> > http://www.freedesktop.org/wiki/Software/systemd/timedated/ or Tizen's
> > vconf
> >
> > #######################################
> >
> >
> > Controversial: ECORE_EVENT_RESET { int argc; char *argv[]; }
> >
> > Emitted when one wants to reset/reload the application with new
> > arguments, effectively like running the application again, but doesn't
> > exit/fork/exec or initialize the libraries again.
> >
> > I think it's controversial but it is used in Tizen. The idea is the
> > application can remain running without resources allocated and when it
> > needs to be used they use a primitive like this to allocate resources
> > and populate them (ie: create a window and show it). This is common
> > for single instance applications, where just one application process
> > should exist, further launches just call the primary to open a new
> > window, could be used by eve/terminology/enjoy..
> >
> > However usually the parameters are not good to receive in text/command
> > line, and may create confusion. For instance in Eve (see below) we
> > parse the command and call an explicit dbus method open_url() with the
> > proper parameters.
> >
> > In Tizen (see below) they use aul and create a "bundle" that is
> > similar to name=Eina_Value, calling the application with that. While I
> > don't really like that, it works in a general way. Thus we could
> > replace int argc, char *argv[] with an array of {const char *name,
> > Eina_Value value;} and work with that. In DBus we could have a generic
> > Open(dict).
> >
> > (you may dislike the bundle/aul, I also dislike it. If it is the case
> > we continue with that I may write a bundle decoder and aul client
> > using pure efl, delivering Eina_Value).
> >
> > See:
> > -
> > https://review.tizen.org/git/?p=framework/appfw/aul-1.git;a=blob;f=src/launch.c;h=5aff5d41777774da4827b7f31efbe54b5331ab23;hb=HEAD
> > -
> > https://review.tizen.org/git/?p=framework/base/bundle.git;a=blob;f=src/bundle.c;h=53df434762b510b4a6ec427d8c995e7de685b9dc;hb=HEAD
> > - http://trac.enlightenment.org/e/browser/trunk/eve/src/bin/main.c
> >
> >
> > Last note: after agreement on this I'll post similar design for
> > Elementary, the window object should receive some signals such as
> > "screen,orientation,changed" if the system wants to automatically
> > rotate the screen if device is swapped, and others such as "suspend"
> > and "resume" if the window is hidden/show and the system wants special
> > actions on those. I've talked to raster and we agree these should be
> > per-window, eventually communicating with the window manager.
> >
>
>
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.
------------------------------------------------------------------------------
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
