Hey,

find the patches attached, they implement what I said. Also attached
is a small test app to print out the values when they change. One can
change it with:

localectl set-locale LC_MESSAGES=en_US LC_CTYPE=pt_BR
timedatectl set-timezone America/Sao_Paulo
sudo date --set="00:00:00"
hostnamectl set-hostname "something"

all of these should generate the events if you're running with
systemd. If you're not, then the "sudo date" should work given that
you have timerfd.

What do you think? (If you like could you commit, I'm out of commit access)



On Thu, Aug 8, 2013 at 3:24 PM, Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> wrote:
> On Thu, Aug 8, 2013 at 3:18 PM, Michael Blumenkrantz
> <michael.blumenkra...@gmail.com> wrote:
>> On Thu, 8 Aug 2013 15:13:01 -0300
>> Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote:
>>
>>> On Thu, Aug 8, 2013 at 3:01 PM, Michael Blumenkrantz
>>> <michael.blumenkra...@gmail.com> wrote:
>>> > On Thu, 8 Aug 2013 14:48:54 -0300
>>> > Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote:
>>> >
>>> >> On Thu, Aug 8, 2013 at 2:31 PM, Michael Blumenkrantz
>>> >> <michael.blumenkra...@gmail.com> wrote:
>>> >> > 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.
>>> >>
>>> >> [..]
>>> >>
>>> >> >
>>> >> > 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.
>>> >>
>>> >>
>>> >> okay, so provide getters and setters (would add the event
>>> >> automatically) but the signal itself shouldn't carry any information?
>>> >> Not even the LOW battery/memory?
>>> >
>>> > I'm thinking that in most cases, we'll just want to send a "low battery" 
>>> > or "low memory" event, no? imo this is what will be useful in most cases. 
>>> > I'm not against having any event structs for new event types, I just 
>>> > think we should be a bit more conservative than we have previously been. 
>>> > If we have a "battery level changed" event, for example, then it makes 
>>> > sense to include the %battery, but if it's "low battery" then it doesn't.
>>>
>>> how do you say you're out of "low battery" state? Create 2 events? 
>>> Cumbersome...
>>
>> you send the event at a certain percentage of the battery, so you'll get it 
>> when going into low battery and out. assuming you also get percentage 
>> events, it should be pretty easy to track. failing that, the user can always 
>> just check whether the battery is currently charging when that event is 
>> received.
>
> actually you could listen to upower's
> http://upower.freedesktop.org/docs/UPower.html#UPower:OnLowBattery
> without checking individual battery levels for each present battery.
> It's automatic, the "low threshold" is configured in a system-wide way
> by UPower, it requires less bandwidth as updates are less frequent and
> easier to use.
>
> For tizen, they use vconf and a single key to indicate low-battery or
> low memory. (sure, strange they use a configuration system to
> propagate that state change).
>
> thus I don't think the levels should be handled or expected in here.
>
>
>
>
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202



-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

Attachment: 0001-ecore-add-system-level-events.patch
Description: Binary data

Attachment: 0002-ecore-detect-and-emit-event-on-system-time-changed.patch
Description: Binary data

Attachment: 0003-ecore-add-system-modules-implement-systemd.patch
Description: Binary data

#include <Ecore.h>
#include <unistd.h>
#include <locale.h>

static Eina_Bool _on_hostname(void *data EINA_UNUSED,
                              int type EINA_UNUSED,
                              void *event_info EINA_UNUSED)
{
   char h[1024];

   gethostname(h, sizeof(h));
   printf("Hostname '%s'\n", h);

   return ECORE_CALLBACK_PASS_ON;
}

static Eina_Bool _on_timedate(void *data EINA_UNUSED,
                              int type EINA_UNUSED,
                              void *event_info EINA_UNUSED)
{
   time_t t = time(NULL);
   char *s = ctime(&t);

   s[strlen(s)] = '\0'; /* remove annoying \n */
   printf("Time and Date: '%s'\n", s);

   return ECORE_CALLBACK_PASS_ON;
}


static Eina_Bool _on_locale(void *data EINA_UNUSED,
                            int type EINA_UNUSED,
                            void *event_info EINA_UNUSED)
{
   struct ldesc {
      int id;
      const char *name;
   };
   const struct ldesc *itr, descs[] = {
     {LC_CTYPE, "LC_CTYPE"},
     {LC_NUMERIC, "LC_NUMERIC"},
     {LC_TIME, "LC_TIME"},
     {LC_COLLATE, "LC_COLLATE"},
     {LC_MONETARY, "LC_MONETARY"},
     {LC_MESSAGES, "LC_MESSAGES"},
     {LC_ALL, "LC_ALL"},
     {LC_PAPER, "LC_PAPER"},
     {LC_NAME, "LC_NAME"},
     {LC_ADDRESS, "LC_ADDRESS"},
     {LC_TELEPHONE, "LC_TELEPHONE"},
     {LC_MEASUREMENT, "LC_MEASUREMENT"},
     {LC_IDENTIFICATION, "LC_IDENTIFICATION"},
     {-1, NULL}
   };
   for (itr = descs; itr->name != NULL; itr++)
     printf("Locale '%s'='%s'\n", itr->name, setlocale(itr->id, NULL));

   return ECORE_CALLBACK_PASS_ON;
}

int main(void)
{
   ecore_init();

   _on_hostname(NULL, 0, NULL);
   ecore_event_handler_add(ECORE_EVENT_HOSTNAME_CHANGED, _on_hostname, NULL);

   _on_timedate(NULL, 0, NULL);
   ecore_event_handler_add(ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED, _on_timedate, NULL);

   _on_locale(NULL, 0, NULL);
   ecore_event_handler_add(ECORE_EVENT_LOCALE_CHANGED, _on_locale, NULL);

   ecore_main_loop_begin();

   ecore_shutdown();
   return 0;
}
------------------------------------------------------------------------------
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