On 09/08/2013, at 23:55, Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:
> On Thu, 8 Aug 2013 13:04:58 -0300 Gustavo Sverzut Barbieri
> <barbi...@profusion.mobi> said:
>
> see below for inline comments :)
>
>> 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).
>
> this one i think is a bit ambiguous. does this mean the shuts down an existing
> instance (eg window) then re-creates it OR does it open a new SECOND window (a
> new instance of itself) which is common for things like browsers (eve),
> gnome-terminal, terminology etc. ? if the process is around with zero windows
> up of course there is only one possible solution... but maybe we need to make
> advice on which to do. the eve example is of course the common one we know,
> but
> i think the name "RESET" for the event makes someone a bit confused as to its
> purpose. maybe "NEW_INSTANCE" is better?
>
> for this to be general i think it needs to provide argv/c as its input - if
> the argv/c content happens to be a "bundle" then so be it, but otherwise this
> won't be useful in a more general sense. so i'd say leave "parsing" up to
> another layer/blob of code and just allow for an argv/c style string set :)
You can send a dict with a key "argc" with a value of int, then a key "argv"
with a value of array of string.
But for terminology you could send the flags u want, like bg/theme.
As for the name, reset is bad.. I'm thinking about Open(). Then define standard
keys/types to help operability, such as files/URL to be used by fileman and
drag and drop.
The app can define when it will replace its main view or open another. Enjoy
would replace, Eve open a new tab and Terminology a new window.
I'm also thinking this can be used to provide "resume". See the wiki page I've
sent in another email. But if we have apps that save their state and exit, we
could request Open() with the window name/class or some other identifier so the
app knows we want to get that window back, from that it could load state and
resume. Enlightenment would then save the window list not of running
applications/windows, but what user created. If user explicitly close the
window then we forget, if the window is closed by non-user then we remember it
and request to be recreated with Open(). Not that useful in desktops but it is
common in Mobile.
We can also avoid abuse and define different methods like a Resume(id). We
could use the id as a value returned by Open() if window class/name is not
good. We could even use ObjectManager and Open would create an object and
return its path, then you operate on that path with calls such as Resume(),
Suspend() and Close(). When daemon exit it would save the hierarchy, reloading
on start.
In elementary that would be something like:
elm_app_register(const char *busname, const Elm_App_Operations *ops, const void
*data), with ops being open, resume, suspend, close... The busname allows one
to register multiple names, such as "telephony" and "messaging" if you handle
both in the same process. Just need to think how to differentiate if Open is
for one or another.
------------------------------------------------------------------------------
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
