They look useful, I'm looking forward to your patch implementing them.

On Thu, Aug 8, 2013 at 1:04 PM, Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> 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.
>
> --
> 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

------------------------------------------------------------------------------
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

Reply via email to