On Sat, 10 Aug 2013 01:12:11 -0300 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
>
> 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.
if we make it just argc/v though then we can merge main() args handling AND the
"restart" handling. from main u do:
handle_restart(argc, argv);
and from the restart event handler.. do the same. :) it is simpler/less work
then for the developer... :)
> But for terminology you could send the flags u want, like bg/theme.
sure... or just cmdline args as passed in already. package them up totally
dumbly... as above... we could even almost automate it and allow any app to do
this "1 process, multiple runs" thing with almost no work... :)
> 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.
open? or new? hmmm. but restart is a bad name indeed. that was my point on it
being confusing.
> 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.
--
------------- 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
