On Thu, 08 Aug 2013 17:16:40 +0100 Tom Hacohen <tom.haco...@samsung.com> said:
> 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.
most of these proposed here are "states" and the events are indicating that
that state changed, so having an empty event info (NULL) and using getters to
get it makes sense.. except for RESET. RESET is transient. it isnt stateful.
you may get 2 or 3 resets in the pipe at once and each with unique args.
> --
> 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.
> >
>
>
> ------------------------------------------------------------------------------
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
