[EGIT] [tools/exactness-elm-data] master 01/02: Update screenshots after freetype update

[Daniel Zaoui]

jackdanielz pushed a commit to branch master.

http://git.enlightenment.org/tools/exactness-elm-data.git/commit/?id=4932a752a172170a9df872389c30ba75175095df

commit 4932a752a172170a9df872389c30ba75175095df
Author: Daniel Zaoui 
Date:   Wed Sep 21 08:00:00 2016 +0300

Update screenshots after freetype update
---
 default-profile/orig/bubble+001.png | Bin 14499 -> 14466 bytes
 default-profile/orig/bubble+002.png | Bin 14558 -> 14552 bytes
 default-profile/orig/bubble+003.png | Bin 13906 -> 13903 bytes
 default-profile/orig/bubble+004.png | Bin 17317 -> 17304 bytes
 default-profile/orig/clock_edit+001.png | Bin 5937 -> 5946 bytes
 default-profile/orig/clock_edit+002.png | Bin 6012 -> 6020 bytes
 default-profile/orig/clock_edit+003.png | Bin 5813 -> 5824 bytes
 default-profile/orig/clock_edit+004.png | Bin 6065 -> 6078 bytes
 default-profile/orig/clock_edit+005.png | Bin 6133 -> 6158 bytes
 default-profile/orig/clock_edit+006.png | Bin 6543 -> 6552 bytes
 default-profile/orig/clock_edit+007.png | Bin 6298 -> 6311 bytes
 default-profile/orig/clock_edit+008.png | Bin 6306 -> 6319 bytes
 default-profile/orig/clock_edit+009.png | Bin 6306 -> 6320 bytes
 default-profile/orig/clock_edit+010.png | Bin 6277 -> 6284 bytes
 default-profile/orig/clock_edit+011.png | Bin 6345 -> 6343 bytes
 default-profile/orig/clock_pause+001.png| Bin 2701 -> 2707 bytes
 default-profile/orig/clock_pause+002.png| Bin 2672 -> 2679 bytes
 default-profile/orig/conformant+001.png | Bin 13974 -> 14043 bytes
 default-profile/orig/conformant+002.png | Bin 13974 -> 14043 bytes
 default-profile/orig/conformant+003.png | Bin 13974 -> 14043 bytes
 default-profile/orig/conformant_2+001.png   | Bin 10024 -> 10002 bytes
 default-profile/orig/conformant_2+002.png   | Bin 9927 -> 9903 bytes
 default-profile/orig/conformant_2+003.png   | Bin 9927 -> 9903 bytes
 default-profile/orig/dayselector+001.png| Bin 8862 -> 8839 bytes
 default-profile/orig/dayselector+002.png| Bin 11773 -> 11753 bytes
 default-profile/orig/dayselector+003.png| Bin 11773 -> 11753 bytes
 default-profile/orig/entry_anchor2+001.png  | Bin 7450 -> 7389 bytes
 default-profile/orig/entry_anchor2+002.png  | Bin 7537 -> 7576 bytes
 default-profile/orig/entry_anchor2+003.png  | Bin 7450 -> 7389 bytes
 default-profile/orig/focus+001.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+002.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+003.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+004.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+005.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+006.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+007.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+008.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+009.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+010.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+011.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+012.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+013.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+014.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+015.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+016.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/focus+017.png  | Bin 60935 -> 62021 bytes
 default-profile/orig/genlist_3+001.png  | Bin 11515 -> 11532 bytes
 default-profile/orig/genlist_3+002.png  | Bin 10517 -> 10537 bytes
 default-profile/orig/genlist_3+003.png  | Bin 10638 -> 10656 bytes
 default-profile/orig/genlist_3+004.png  | Bin 10712 -> 10738 bytes
 default-profile/orig/genlist_3+005.png  | Bin 11738 -> 11754 bytes
 default-profile/orig/genlist_3+006.png  | Bin 11726 -> 11746 bytes
 default-profile/orig/genlist_3+007.png  | Bin 11601 -> 11608 bytes
 default-profile/orig/genlist_4+001.png  | Bin 15480 -> 15510 bytes
 default-profile/orig/genlist_4+002.png  | Bin 27160 -> 27210 bytes
 default-profile/orig/genlist_4+003.png  | Bin 38728 -> 38782 bytes
 default-profile/orig/genlist_4+004.png  | Bin 38728 -> 38782 bytes
 default-profile/orig/genlist_4+005.png  | Bin 27160 -> 27210 bytes
 default-profile/orig/genlist_4+006.png  

[EGIT] [tools/exactness-elm-data] master 02/02: flipselector: update scenario and screenshots

[Daniel Zaoui]

jackdanielz pushed a commit to branch master.

http://git.enlightenment.org/tools/exactness-elm-data.git/commit/?id=8e113b35a641d3ababe8a428ccdd7d971525ddcc

commit 8e113b35a641d3ababe8a428ccdd7d971525ddcc
Author: Daniel Zaoui 
Date:   Thu Sep 22 07:50:27 2016 +0300

flipselector: update scenario and screenshots
---
 default-profile/orig/flipselector+001.png   | Bin 14346 -> 15886 bytes
 default-profile/orig/flipselector+002.png   | Bin 14438 -> 15981 bytes
 default-profile/orig/flipselector+003.png   | Bin 14540 -> 15960 bytes
 default-profile/orig/flipselector+004.png   | Bin 14636 -> 16080 bytes
 default-profile/orig/flipselector+005.png   | Bin 14611 -> 16080 bytes
 default-profile/orig/flipselector+006.png   | Bin 14463 -> 16175 bytes
 default-profile/orig/flipselector+007.png   | Bin 14437 -> 16004 bytes
 default-profile/orig/flipselector+008.png   | Bin 0 -> 16019 bytes
 default-profile/orig/flipselector+009.png   | Bin 0 -> 15980 bytes
 default-profile/recordings/flipselector.rec | Bin 3362 -> 3623 bytes
 10 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/default-profile/orig/flipselector+001.png 
b/default-profile/orig/flipselector+001.png
index 6943dfe..ce81e86 100644
Binary files a/default-profile/orig/flipselector+001.png and 
b/default-profile/orig/flipselector+001.png differ
diff --git a/default-profile/orig/flipselector+002.png 
b/default-profile/orig/flipselector+002.png
index c4201db..26f7309 100644
Binary files a/default-profile/orig/flipselector+002.png and 
b/default-profile/orig/flipselector+002.png differ
diff --git a/default-profile/orig/flipselector+003.png 
b/default-profile/orig/flipselector+003.png
index df6c7c7..2b12364 100644
Binary files a/default-profile/orig/flipselector+003.png and 
b/default-profile/orig/flipselector+003.png differ
diff --git a/default-profile/orig/flipselector+004.png 
b/default-profile/orig/flipselector+004.png
index 8234b58..003c5f4 100644
Binary files a/default-profile/orig/flipselector+004.png and 
b/default-profile/orig/flipselector+004.png differ
diff --git a/default-profile/orig/flipselector+005.png 
b/default-profile/orig/flipselector+005.png
index 209e5f3..003c5f4 100644
Binary files a/default-profile/orig/flipselector+005.png and 
b/default-profile/orig/flipselector+005.png differ
diff --git a/default-profile/orig/flipselector+006.png 
b/default-profile/orig/flipselector+006.png
index 9c79ab1..cda 100644
Binary files a/default-profile/orig/flipselector+006.png and 
b/default-profile/orig/flipselector+006.png differ
diff --git a/default-profile/orig/flipselector+007.png 
b/default-profile/orig/flipselector+007.png
index 358b35b..1a715a1 100644
Binary files a/default-profile/orig/flipselector+007.png and 
b/default-profile/orig/flipselector+007.png differ
diff --git a/default-profile/orig/flipselector+008.png 
b/default-profile/orig/flipselector+008.png
new file mode 100644
index 000..d7f7e83
Binary files /dev/null and b/default-profile/orig/flipselector+008.png differ
diff --git a/default-profile/orig/flipselector+009.png 
b/default-profile/orig/flipselector+009.png
new file mode 100644
index 000..dce3cb6
Binary files /dev/null and b/default-profile/orig/flipselector+009.png differ
diff --git a/default-profile/recordings/flipselector.rec 
b/default-profile/recordings/flipselector.rec
index 4c195c0..6e05e63 100644
Binary files a/default-profile/recordings/flipselector.rec and 
b/default-profile/recordings/flipselector.rec differ

-- 

[EGIT] [core/efl] master 01/01: photocam: add missing EOLIAN prefix

[Amitesh Singh]

ami pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=834222d3a019e548a238a59f040f869487c14adc

commit 834222d3a019e548a238a59f040f869487c14adc
Author: Amitesh Singh 
Date:   Thu Sep 22 10:34:54 2016 +0530

photocam: add missing EOLIAN prefix
---
 src/lib/elementary/elm_photocam.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/elementary/elm_photocam.c 
b/src/lib/elementary/elm_photocam.c
index 5876646..aac9448 100644
--- a/src/lib/elementary/elm_photocam.c
+++ b/src/lib/elementary/elm_photocam.c
@@ -2191,7 +2191,7 @@ _elm_photocam_gesture_enabled_get(Eo *obj EINA_UNUSED, 
Elm_Photocam_Data *sd)
return sd->do_gesture;
 }
 
-static void
+EOLIAN static void
 _elm_photocam_class_constructor(Efl_Class *klass)
 {
evas_smart_legacy_type_register(MY_CLASS_NAME_LEGACY, klass);

-- 

[EGIT] [tools/exactness] master 01/02: Recording: support new EFL input events

[Daniel Zaoui]

jackdanielz pushed a commit to branch master.

http://git.enlightenment.org/tools/exactness.git/commit/?id=95327a0f7c1fd38d866fd58cdec1b2f926347937

commit 95327a0f7c1fd38d866fd58cdec1b2f926347937
Author: Daniel Zaoui 
Date:   Thu Sep 22 07:28:56 2016 +0300

Recording: support new EFL input events

During recording, hooking on Evas functions can't work anymore as they
are no more invoked internally.
The new way to catch the events is to listen to them on the canvas.
Additionally, regular mouse events are now multi events whose tool (device 
id)
is 0, as well as key events with and without keycode are now always
considered with a keycode that can be 0.

Previous events catching has been kept to support legacy applications.
---
 src/bin/exactness_helper.c |  14 +-
 src/lib/tsuite_evas_hook.c | 331 -
 src/lib/tsuite_file_data.c |   1 +
 src/lib/tsuite_file_data.h |   1 +
 4 files changed, 282 insertions(+), 65 deletions(-)

diff --git a/src/bin/exactness_helper.c b/src/bin/exactness_helper.c
index ab5cc03..12945b2 100644
--- a/src/bin/exactness_helper.c
+++ b/src/bin/exactness_helper.c
@@ -76,15 +76,21 @@ _event_specific_info_get(const Variant_st *v, char 
output[1024])
   case TSUITE_EVENT_MULTI_DOWN: case TSUITE_EVENT_MULTI_UP:
{
   multi_event *t = v->data;
-  sprintf(output, "D %d X %d Y %d Rad %f RadX %f RadY %f Pres %f 
Ang %f FX %f FY %f Flags %d",
-t->d, t->x, t->y, t->rad, t->radx, t->rady, t->pres, 
t->ang, t->fx, t->fy, t->flags);
+  if (!t->d)
+ sprintf(output, "Button %d Flags %d", t->b, t->flags);
+  else
+ sprintf(output, "D %d X %d Y %d Rad %f RadX %f RadY %f Pres 
%f Ang %f FX %f FY %f Flags %d",
+   t->d, t->x, t->y, t->rad, t->radx, t->rady, t->pres, 
t->ang, t->fx, t->fy, t->flags);
   break;
}
   case TSUITE_EVENT_MULTI_MOVE:
{
   multi_move *t = v->data;
-  sprintf(output, "D %d X %d Y %d Rad %f RadX %f RadY %f Pres %f 
Ang %f FX %f FY %f",
-t->d, t->x, t->y, t->rad, t->radx, t->rady, t->pres, 
t->ang, t->fx, t->fy);
+  if (!t->d)
+ sprintf(output, "X %d Y %d", t->x, t->y);
+  else
+ sprintf(output, "D %d X %d Y %d Rad %f RadX %f RadY %f Pres 
%f Ang %f FX %f FY %f",
+   t->d, t->x, t->y, t->rad, t->radx, t->rady, t->pres, 
t->ang, t->fx, t->fy);
   break;
}
   case TSUITE_EVENT_KEY_UP: case TSUITE_EVENT_KEY_DOWN:
diff --git a/src/lib/tsuite_evas_hook.c b/src/lib/tsuite_evas_hook.c
index e2dcdf7..20eb596 100644
--- a/src/lib/tsuite_evas_hook.c
+++ b/src/lib/tsuite_evas_hook.c
@@ -1,4 +1,7 @@
 #define _GNU_SOURCE 1
+#define EFL_EO_API_SUPPORT
+#define EFL_BETA_API_SUPPORT
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +46,94 @@ static Tsuite_Data ts;
 static Eina_List *evas_list = NULL; /* List of Evas pointers */
 static int ignore_evas_new = 0; /* Counter to know if we should ignore evas 
new or not. */
 
+static Tsuite_Event_Type
+tsuite_event_pointer_type_get(Efl_Pointer_Action t)
+{
+   switch(t)
+ {
+  case EFL_POINTER_ACTION_IN: return TSUITE_EVENT_MOUSE_IN;
+  case EFL_POINTER_ACTION_OUT: return TSUITE_EVENT_MOUSE_OUT;
+  case EFL_POINTER_ACTION_DOWN: return TSUITE_EVENT_MULTI_DOWN;
+  case EFL_POINTER_ACTION_UP: return TSUITE_EVENT_MULTI_UP;
+  case EFL_POINTER_ACTION_MOVE: return TSUITE_EVENT_MULTI_MOVE;
+  case EFL_POINTER_ACTION_WHEEL: return TSUITE_EVENT_MOUSE_WHEEL;
+  default:
+ return TSUITE_EVENT_NOT_SUPPORTED;
+ }
+}
+
+#ifdef DEBUG_TSUITE
+static const char *
+_event_name_get(Tsuite_Event_Type type)
+{
+   switch(type)
+ {
+  case TSUITE_EVENT_MOUSE_IN: return "Mouse In";
+  case TSUITE_EVENT_MOUSE_OUT: return "Mouse Out";
+  case TSUITE_EVENT_MOUSE_DOWN: return "Mouse Down";
+  case TSUITE_EVENT_MOUSE_UP: return "Mouse Up";
+  case TSUITE_EVENT_MOUSE_MOVE: return "Mouse Move";
+  case TSUITE_EVENT_MOUSE_WHEEL: return "Mouse Wheel";
+  case TSUITE_EVENT_MULTI_DOWN: return "Multi Down";
+  case TSUITE_EVENT_MULTI_UP: return "Multi Up";
+  case TSUITE_EVENT_MULTI_MOVE: return "Multi Move";
+  case TSUITE_EVENT_KEY_DOWN: return "Key Down";
+  case TSUITE_EVENT_KEY_UP: return "Key Up";
+  case TSUITE_EVENT_KEY_DOWN_WITH_KEYCODE: return "Key Down with Keycode";
+  case TSUITE_EVENT_KEY_UP_WITH_KEYCODE: return "Key Up with Keycode";
+  case TSUITE_EVENT_TAKE_SHOT: return "Take shot";
+  default: return NULL;
+ }
+}
+#endif
+
+static Eina_Bool
+_is_hook_duplicate(const Variant_st *v, Tsuite_Event_Type ev_type, const void 
*info, int len)
+{
+   if (v->t.type == tsuite_event_mapping_type_str_get(ev_type) &&
+ !memcmp(v->data, 

[EGIT] [tools/exactness] master 02/02: Modify macro to prevent simple-but-hard-to-find bugs

[Daniel Zaoui]

jackdanielz pushed a commit to branch master.

http://git.enlightenment.org/tools/exactness.git/commit/?id=1ad03a2e49000fbeda0f43306518743e3048e810

commit 1ad03a2e49000fbeda0f43306518743e3048e810
Author: Daniel Zaoui 
Date:   Thu Sep 22 07:52:27 2016 +0300

Modify macro to prevent simple-but-hard-to-find bugs

One of them is to forget to replace the struct name during a line copy,
leading to write bad data in the recording file and to its corruption.
---
 src/lib/tsuite_evas_hook.c | 69 +-
 1 file changed, 26 insertions(+), 43 deletions(-)

diff --git a/src/lib/tsuite_evas_hook.c b/src/lib/tsuite_evas_hook.c
index 20eb596..268ec18 100644
--- a/src/lib/tsuite_evas_hook.c
+++ b/src/lib/tsuite_evas_hook.c
@@ -96,19 +96,19 @@ _is_hook_duplicate(const Variant_st *v, Tsuite_Event_Type 
ev_type, const void *i
 }
 
 /* Adding variant to list, this list is later written to EET file */
-#define ADD_TO_LIST(EVT_TYPE, EVT_STRUCT_NAME, INFO) \
+#define ADD_TO_LIST(EVT_TYPE, INFO) \
do { /* This macro will add event to EET data list */ \
 if (vr_list && _hook_setting->recording) \
   { \
  const Variant_st *prev_v = 
eina_list_last_data_get(vr_list->variant_list); \
- if (!prev_v || !_is_hook_duplicate(prev_v, EVT_TYPE, , 
sizeof(EVT_STRUCT_NAME))) \
+ if (!prev_v || !_is_hook_duplicate(prev_v, EVT_TYPE, , 
sizeof(INFO))) \
{ \
   printf("Recording %s\n", 
tsuite_event_mapping_type_str_get(EVT_TYPE)); \
   Variant_st *v =  malloc(sizeof(Variant_st)); \
-  v->data = malloc(sizeof(EVT_STRUCT_NAME)); \
+  v->data = malloc(sizeof(INFO)); \
   
_variant_type_set(tsuite_event_mapping_type_str_get(EVT_TYPE), \
 >t, EINA_FALSE); \
-  memcpy(v->data, , sizeof(EVT_STRUCT_NAME)); \
+  memcpy(v->data, , sizeof(INFO)); \
   vr_list->variant_list = 
eina_list_append(vr_list->variant_list, v); \
} \
   } \
@@ -444,7 +444,7 @@ _event_pointer_cb(void *data, const Efl_Event *event)
  int x = 0, y = 0;
  efl_input_pointer_position_get(evp, , );
  multi_move t = { tool, x, y, rad, radx, rady, pres, ang, fx, fy, 
timestamp, n_evas };
- if (t.n_evas >= 0) ADD_TO_LIST(evt, multi_move, t);
+ if (t.n_evas >= 0) ADD_TO_LIST(evt, t);
  break;
   }
   case EFL_POINTER_ACTION_DOWN: case EFL_POINTER_ACTION_UP:
@@ -457,13 +457,13 @@ _event_pointer_cb(void *data, const Efl_Event *event)
  Efl_Pointer_Flags flags = efl_input_pointer_button_flags_get(evp);
  multi_event t = { tool, b, x, y, rad, radx, rady, pres, ang,
   fx, fy, flags, timestamp, n_evas };
- if (t.n_evas >= 0) ADD_TO_LIST(evt, multi_event, t);
+ if (t.n_evas >= 0) ADD_TO_LIST(evt, t);
  break;
   }
   case EFL_POINTER_ACTION_IN: case EFL_POINTER_ACTION_OUT:
   {
  mouse_in_mouse_out t = { timestamp, n_evas };
- if (t.n_evas >= 0) ADD_TO_LIST(evt, mouse_in_mouse_out, t);
+ if (t.n_evas >= 0) ADD_TO_LIST(evt, t);
  break;
   }
   case EFL_POINTER_ACTION_WHEEL:
@@ -471,7 +471,7 @@ _event_pointer_cb(void *data, const Efl_Event *event)
  int direction = efl_input_pointer_wheel_direction_get(evp);
  int z = efl_input_pointer_wheel_delta_get(evp);
  mouse_wheel t = { direction, z, timestamp, n_evas };
- if (t.n_evas >= 0) ADD_TO_LIST(evt, mouse_wheel, t);
+ if (t.n_evas >= 0) ADD_TO_LIST(evt, t);
  break;
   }
   default:
@@ -498,8 +498,7 @@ _event_key_cb(void *data, const Efl_Event *event)
  printf("Take Screenshot: %s timestamp=<%u>\n", __func__, 
timestamp);
 #endif
  take_screenshot t = { timestamp, n_evas };
- if (t.n_evas >= 0)
-ADD_TO_LIST(TSUITE_EVENT_TAKE_SHOT, take_screenshot, t);
+ if (t.n_evas >= 0) ADD_TO_LIST(TSUITE_EVENT_TAKE_SHOT, t);
  return;
   }
 if (!strcmp(key, SAVE_KEY_STR))
@@ -530,7 +529,7 @@ _event_key_cb(void *data, const Efl_Event *event)
 t.compose = eina_stringshare_add(efl_input_key_compose_get(evk));
 t.keycode = efl_input_key_code_get(evk);
 t.n_evas = n_evas;
-if (t.n_evas >= 0) ADD_TO_LIST(evt, key_down_key_up_with_keycode, t);
+if (t.n_evas >= 0) ADD_TO_LIST(evt, t);
  }
 }
 
@@ -953,8 +952,7 @@ evas_event_feed_mouse_in(Evas *e, unsigned int timestamp, 
const void *data)
 #endif
mouse_in_mouse_out t = { timestamp, evas_list_find(e) };
int evt = tsuite_event_type_get(EVAS_CALLBACK_MOUSE_IN);
-   if (t.n_evas >= 0)
- ADD_TO_LIST(evt, mouse_in_mouse_out, t);
+   if 

[E-devel] FW: [EGIT] [core/efl] master 01/01: edje/edje_cc: use strncpy() instead of strcpy().

[Hermet Park]

Yeah actually here security point is meaningless buf *IF* a attacker 
intentionally breaks the string buffer in edje_cc.
strcpy() is the one of the easy points to hack the program by attackers.

Regardless of it, still, I hate these repeated reports from static code 
analyziers such as coverity.

So changed.

-Original Message-
From: "Carsten Haitzler" 
To: "Enlightenment developer list"; 
Cc: ; 
Sent: 2016-09-22 (목) 08:24:04
Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: edje/edje_cc: use 
strncpy() instead of strcpy().
 
On Wed, 21 Sep 2016 09:19:57 -0300 Gustavo Sverzut Barbieri
 said:

> On Wed, Sep 21, 2016 at 1:32 AM, ChunEon Park  wrote:
> > hermet pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=ab1a72f5e7df6fe0adef54bdcddd9867a2ebe3a6
> >
> > commit ab1a72f5e7df6fe0adef54bdcddd9867a2ebe3a6
> > Author: Hermet Park 
> > Date:   Wed Sep 21 13:30:44 2016 +0900
> >
> > edje/edje_cc: use strncpy() instead of strcpy().
> >
> > strncpy() is better for security.
> > Also, this change avoids annoying coverity detection.
> > ---
> >  src/bin/edje/edje_cc_parse.c  2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/bin/edje/edje_cc_parse.c b/src/bin/edje/edje_cc_parse.c
> > index 525c71d..efabe22 100644
> > --- a/src/bin/edje/edje_cc_parse.c
> > +++ b/src/bin/edje/edje_cc_parse.c
> > @@ -391,7 +391,7 @@ next_token(char *p, char *end, char **new_p, int *delim)
> >   l = sscanf(tmpstr, "%*s %i \"%[^\"]\"", , fl);
> >   if (l == 2)
> > {
> > -  strcpy(file_buf, fl);
> > +  strncpy(file_buf, fl, sizeof(file_buf));
> >line = nm;
> >file_in = file_buf;
> > }
> 
> 
> the proper function to call is eina_strlcpy(), it will use strlcpy()
> if available, otherwise will ensure the nul byte.

actually the proper thing to do is... not change the code at all. read it. it's
safe. file_buf is 4096. fl is 4096. it CANNOT overflow by definition as the
string being copied into the target cannot be bigger.

people need to be careful of this kind of "well someone told me to use strncpy
because its safe". especially if it becomes a blindly applied "rule". read the
code. there is a chance you actually may break it by doing such changes (this
change doesn't).

in fact if there is an issue it's in the sscanf into the fl buffer which places
no limits on len (and fl is limited). of course ... the file path would have to
be insanely huge for this to happen and it'd be an invalid path in most
environments so things would fail one way or another... what edc files used to
exploit edje_cc? at this point we're compiling stuff so... all bets are off
anyway. so security isn't the issue imho.

anyway. point being - this code fixes NO BUG. it doesnt make code any safer.
what it does do is totally miss the actual potential bug in the sscanf :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/01: scrollable_interface: fixed gravity_set() API.

[Hosang Kim]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f148296ed1a175bb09a9a14f518974bfdec292b1

commit f148296ed1a175bb09a9a14f518974bfdec292b1
Author: Hosang Kim 
Date:   Wed Sep 21 20:44:53 2016 +0900

scrollable_interface: fixed gravity_set() API.

Summary: elm_scroller_gravity_set()  API is not working.

Test Plan: elementary_test -> scroller3

Reviewers: jaehwan, SanghyeonLee, Hermet, jypark, raster, cedric

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4252
---
 src/bin/elementary/test_scroller.c| 25 +++-
 src/lib/elementary/elm_interface_scrollable.c | 57 ++-
 src/lib/elementary/elm_interface_scrollable.h |  6 ++-
 src/lib/elementary/elm_pan.eo | 10 -
 4 files changed, 40 insertions(+), 58 deletions(-)

diff --git a/src/bin/elementary/test_scroller.c 
b/src/bin/elementary/test_scroller.c
index 2221f80..04b6c80 100644
--- a/src/bin/elementary/test_scroller.c
+++ b/src/bin/elementary/test_scroller.c
@@ -593,6 +593,15 @@ _append_items(void *data, Evas_Object *obj EINA_UNUSED, 
void *event_info EINA_UN
 }
 
 static void
+_changed_cb(void *data, Evas_Object *obj EINA_UNUSED, void *event_info 
EINA_UNUSED)
+{
+   Evas_Object *sl = data;
+   double val = elm_slider_value_get(obj);
+   elm_scroller_gravity_set(sl, 0.0, val);
+   printf("Gravity change to %lf\n",val);
+}
+
+static void
 _win_del_cb(void *data EINA_UNUSED,
Evas *e EINA_UNUSED,
Evas_Object *obj EINA_UNUSED,
@@ -605,7 +614,7 @@ _win_del_cb(void *data EINA_UNUSED,
 void
 test_scroller3(void *data EINA_UNUSED, Evas_Object *obj EINA_UNUSED, void 
*event_info EINA_UNUSED)
 {
-   Evas_Object *win, *bt, *bt2, *bt3, *bx, *bx2, *bx3, *bx4, *sc;
+   Evas_Object *win, *bt, *bt2, *bt3, *bx, *bx2, *bx3, *bx4, *sc, *sl;
_count = 0;
 
win = elm_win_util_standard_add("scroller3", "Scroller 3");
@@ -639,9 +648,20 @@ test_scroller3(void *data EINA_UNUSED, Evas_Object *obj 
EINA_UNUSED, void *event
elm_box_pack_end(bx2, bt3);
evas_object_show(bt3);
 
+   sl = elm_slider_add(bx);
+   elm_object_text_set(sl, "Gravity");
+   elm_slider_unit_format_set(sl, "%1.1f");
+   elm_slider_indicator_format_set(sl, "%1.1f");
+   elm_slider_min_max_set(sl, 0, 1);
+   elm_slider_value_set(sl, 0.0);
+   evas_object_size_hint_align_set(sl, EVAS_HINT_FILL, EVAS_HINT_FILL);
+   evas_object_size_hint_weight_set(sl, EVAS_HINT_EXPAND, 0.1);
+   elm_box_pack_end(bx, sl);
+   evas_object_show(sl);
+
bx3 = elm_box_add(bx);
evas_object_size_hint_align_set(bx3, EVAS_HINT_FILL, EVAS_HINT_FILL);
-   evas_object_size_hint_weight_set(bx3, EVAS_HINT_EXPAND, 0.9);
+   evas_object_size_hint_weight_set(bx3, EVAS_HINT_EXPAND, 0.8);
elm_box_pack_end(bx, bx3);
evas_object_show(bx3);
 
@@ -660,6 +680,7 @@ test_scroller3(void *data EINA_UNUSED, Evas_Object *obj 
EINA_UNUSED, void *event
evas_object_smart_callback_add(bt, "clicked", _append_item, bx4);
evas_object_smart_callback_add(bt2, "clicked", _prepend_item, bx4);
evas_object_smart_callback_add(bt3, "clicked", _append_items, bx4);
+   evas_object_smart_callback_add(sl, "changed", _changed_cb, sc);
 
evas_object_resize(win, 500, 500);
evas_object_show(win);
diff --git a/src/lib/elementary/elm_interface_scrollable.c 
b/src/lib/elementary/elm_interface_scrollable.c
index 819ba2b..f43bc0a 100644
--- a/src/lib/elementary/elm_interface_scrollable.c
+++ b/src/lib/elementary/elm_interface_scrollable.c
@@ -82,25 +82,7 @@ _round(double value, int pos)
 static void
 _elm_pan_update(Elm_Pan_Smart_Data *psd)
 {
-   if (!psd->gravity_x && !psd->gravity_y)
- {
-evas_object_move(psd->content, psd->x - psd->px, psd->y - psd->py);
-return;
- }
-
-   if ((!psd->px) && (!psd->py))
- {
-psd->px = psd->delta_posx * psd->gravity_x;
-psd->py = psd->delta_posy * psd->gravity_y;
- }
-   psd->delta_posx += psd->content_w - psd->prev_cw;
-   psd->prev_cw = psd->content_w;
-   psd->delta_posy += psd->content_h - psd->prev_ch;
-   psd->prev_ch = psd->content_h;
-
evas_object_move(psd->content, psd->x - psd->px, psd->y - psd->py);
-   psd->px = psd->delta_posx * psd->gravity_x;
-   psd->py = psd->delta_posy * psd->gravity_y;
 }
 
 EOLIAN static void
@@ -205,24 +187,6 @@ _elm_pan_content_size_get(Eo *obj EINA_UNUSED, 
Elm_Pan_Smart_Data *psd, Evas_Coo
if (h) *h = psd->content_h;
 }
 
-EOLIAN static void
-_elm_pan_gravity_set(Eo *obj EINA_UNUSED, Elm_Pan_Smart_Data *psd, double x, 
double y)
-{
-   psd->gravity_x = x;
-   psd->gravity_y = y;
-   psd->prev_cw = psd->content_w;
-   psd->prev_ch = psd->content_h;
-   psd->delta_posx = 0;
-   psd->delta_posy = 0;
-}
-
-EOLIAN static void
-_elm_pan_gravity_get(Eo *obj EINA_UNUSED, Elm_Pan_Smart_Data *psd, double *x, 
double *y)
-{
-   if (x) *x = psd->gravity_x;
-   if (y) *y 

Re: [E-devel] Efl.Net and libproxy

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 8:13 PM, Carsten Haitzler  wrote:
> On Wed, 21 Sep 2016 11:29:00 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> On Wed, Sep 21, 2016 at 9:08 AM, Carsten Haitzler 
>> wrote:
>> > On Tue, 20 Sep 2016 19:12:57 -0300 Gustavo Sverzut Barbieri
>> >  said:
>> >
>> >> damn raster... I had to do so I could check.
>> >>
>> >> dlopen -> in git.
>> >>
>> >> server and libproxy.so wrapper, attached with the basics, I'm not
>> >> doing all the cumbersome details to get a single process running and
>> >> spawn it from libproxy.so wrapper without a race condition.
>> >
>> > there is no race.
>> >
>> > connect. if connect fail, spawn, set timer to connect every 0.1 sec until
>> > successful.
>> >
>> > there is no race. first daemon spawned that binds to the socket wins. every
>> > other one will fail and exit. there is no race to deal with as the bind 
>> > does
>> > the job for the daemon - first one in wins and the rest fail.
>>
>> there is a problem with stale sockets. If daemon dies and leaves the
>> socket file, then next daemons will try to bind and fail... then
>> nobody wins. If we first unlink(), then there is a race.
>>
>> Or should we use an abstract socket?
>
> or ... never die. ever. once up, stay up (of course until session shuts down).
> unless of course it's a crash/bug/segv in which case there is no unlink. :)

we never crash :-D

seriously, this is not possible.


>> >> I'd simplify all of that by using dbus with acquiring a name in the
>> >> session bus and let that entity control it. Also would let the dbus
>> >> daemon set isolation, like not inheriting current processes limits,
>> >> namespaces and all.
>> >
>> > no it isn't any easier with dbus. see above. this is what efreetd does not.
>> > its REALLyYsimple and race-free.
>>
>> still doesn't address inheriting caps and other access controls...
>
> efreetd doesnt need such caps. neither does this efl.proxy. remember how i
> differentiated between "global resources" vs things like thumbnails where
> thumbs are not global resources - they are directly tied tot he src file and
> permissions on it and the permissions of the app etc.
>
> a "proxy lookup" daemon is going to provide a global resource - the ability to
> take an input target machine and give a resulting proxy server to use, and 
> that
> global resource may be as simple as an $http_proxy env var, or as complex as a
> bunch of js in a pac file to execute to figure out which proxy to use.

that's the case, you may need to talk to some configuration daemon
(ie: gsettings) or even the network (ie: http://wpad/wpad.dat or
http://wpad.${searchdomain}/wpad.dat) and then you may be limited by
some inherited capability.

then you're right the daemon and its output is global, however it may
be launched from a specific scope and thus not delivering what it
should.



>> say constrained process A spawned the daemon. Then unconstrained
>> process B will get the constraints.
>
> in a constrained environment like one with SMACK this daemon would launch as
> part of your login session. such constrained environments have to deal with
> this. they could also set up systemd socket activation too. efreetd - same
> story. outside of such env's the "i'll launch if i can't connect" just works
> (tm).

this is what I suggest, to launch it elsewhere. I mentioned systemd,
you also mention systemd here... but then, right below you bash that
option :-/ note that is only an example of a possibility, it's not
mandated.


>> more concrete description is: for some reason "A" was started without
>> network access. The daemon inherits that and thus libproxy won't work.
>> That's okay, expected.
>
> actually it'd still work because proxy daemon is doing a lookup locally as to
> what to use. the app itself still does the connect and thus gets blocked. the
> proxy daemon isnt meant to be doing dns lookups or anything else - just return
> the $http_proxy to use or runt he js to figure out what proxy to use given a
> nice fat bit of data in the pac file to choose what may be internal and/or
> external sites by name/ip etc. and what proxy to use.

no, that may be accessing an URL in the case user choose PAC (Proxy
Auto Configuration), which is recommended in most setups.

it will then need HTTP and DNS access.

some configuration input, like for official libproxy, will need
gsettings access. Others will need dbus (ie: pacrunner). If we go
crazy and reimplement that ourselves in EFL, we still need file access
-- as you know that comes with constraints.


>> However "B" has network access and is started afterwards, it will
>> check and the daemon is there. It will use the daemon with libproxy
>> that doesn't work due lack of network access. This is not expected.
>>
>> I know not all systems employ fine grained capabilities and
>> smack/selinux, but some do and we need to be careful.
>
> such constrained environments have to 

Re: [E-devel] [EGIT] [core/efl] master 02/02: ecore_con, elput: fix warnings

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 8:35 PM, Carsten Haitzler  wrote:
> On Tue, 20 Sep 2016 23:21:55 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> On Tue, Sep 20, 2016 at 8:26 PM, Bruno Dilly  wrote:
>> > cedric pushed a commit to branch master.
>> >
>> > http://git.enlightenment.org/core/efl.git/commit/?id=a3fba57b2616f78fbdab7b43ac8e8aea7c56475b
>> >
>> > commit a3fba57b2616f78fbdab7b43ac8e8aea7c56475b
>> > Author: Bruno Dilly 
>> > Date:   Tue Sep 20 16:13:25 2016 -0700
>> >
>> > ecore_con,elput: fix warnings
>> >
>> > Summary:
>> > elput: fix warning for unused write result
>> >  ecore_con: fix warning for unused asprintf result
>> >
>> > Reviewers: iscaro, devilhorns, cedric
>> >
>> > Reviewed By: cedric
>> >
>> > Subscribers: cedric, seoz, jpeg
>> >
>> > Differential Revision: https://phab.enlightenment.org/D4308
>> >
>> > Signed-off-by: Cedric BAIL 
>> > ---
>> >  src/lib/ecore_con/ecore_con.c | 15 +++
>> >  src/lib/elput/elput_logind.c  | 14 +-
>> >  2 files changed, 24 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/src/lib/ecore_con/ecore_con.c b/src/lib/ecore_con/ecore_con.c
>> > index cc17fe8..cb66b27 100644
>> > --- a/src/lib/ecore_con/ecore_con.c
>> > +++ b/src/lib/ecore_con/ecore_con.c
>> > @@ -4487,11 +4487,18 @@ _efl_net_ip_connect_async_run(void *data,
>> > Ecore_Thread *thread EINA_UNUSED)
>> >   * parameter must be a URL with schema, otherwise it won't
>> >   * return anything.
>> >   */
>> > -char *url;
>> > +Eina_Stringshare *url;
>> >
>> > -asprintf(, "%s://%s:%s", d->protocol == IPPROTO_UDP ? "udp" :
>> > "tcp", host, port);
>> > -proxies = ecore_con_libproxy_proxies_get(url);
>> > -free(url);
>> > +url = eina_stringshare_printf("%s://%s:%s", d->protocol ==
>> > IPPROTO_UDP ? "udp" : "tcp", host, port);
>> > +if (!url)
>> > +  {
>> > + ERR("Could not assemble URL");
>> > +  }
>> > +else
>> > +  {
>> > + proxies = ecore_con_libproxy_proxies_get(url);
>> > + eina_stringshare_del(url);
>> > +  }
>>
>> why are you using stringshare here?
>>
>>  - this is used only once, share makes no benefit.
>>
>>  - this is used from thread, not sure eina stringshare is thread safe.
>>
>> if it's complaining about asprintf() on some weirdo platform, we can
>> malloc + memcpy the pieces
>
> last i knew asnprintf is "not portable" like strdupa. alloca is about the only
> thing we can trust to work. :)

asprintf() is simple:

static inline int asprintf(...) {
int len = snprintf("", 0, ...);
char *buf = malloc(len + 1);
snprintf(buf, len + 1, ...);
}

strdupa is not listed above, but also implementable as a macro:

#define strdupa(str) ({char *__buf = alloca(strlen(str) + 1);
memcpy(__buf, str, strlen(str) + 1); buf})





-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: protect against non-nul terminated string from mmap in filepreview

[Cedric BAIL]

On Wed, Sep 21, 2016 at 4:32 PM, Carsten Haitzler  wrote:
> On Wed, 21 Sep 2016 08:33:11 -0700 Cedric BAIL  said:
>> On Sep 21, 2016 4:18 AM, "Carsten Haitzler"  wrote:
>> > raster pushed a commit to branch master.
>> >
>> >
>> http://git.enlightenment.org/core/enlightenment.git/commit/?id=5861d9bef949c64cbc7ddad31b4ac2cc70bb6440
>> >
>> > commit 5861d9bef949c64cbc7ddad31b4ac2cc70bb6440
>> > Author: Carsten Haitzler (Rasterman) 
>> > Date:   Wed Sep 21 20:18:01 2016 +0900
>> >
>> > protect against non-nul terminated string from mmap in filepreview
>> >
>> > this should address 2nd gdb bt and fix T4543
>>
>> No ! This patch is unnecessary or more exactly too late. Previous code was
>> using the _n variant of append which call strlen. The current code only
>> rely on the given length. Will revert.
>
> why on earth is it doing strlen when obviously n bytes are to go in (or until
> the nul byte)?

It is the same difference as memcpy and strncpy. One take the original
pointer as just data, the other as a string. So the _n variant is the
one that does call strlen to get the max number of character to copy.
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: ecore_con, elput: fix warnings

[The Rasterman]

On Tue, 20 Sep 2016 23:21:55 -0300 Gustavo Sverzut Barbieri
 said:

> On Tue, Sep 20, 2016 at 8:26 PM, Bruno Dilly  wrote:
> > cedric pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=a3fba57b2616f78fbdab7b43ac8e8aea7c56475b
> >
> > commit a3fba57b2616f78fbdab7b43ac8e8aea7c56475b
> > Author: Bruno Dilly 
> > Date:   Tue Sep 20 16:13:25 2016 -0700
> >
> > ecore_con,elput: fix warnings
> >
> > Summary:
> > elput: fix warning for unused write result
> >  ecore_con: fix warning for unused asprintf result
> >
> > Reviewers: iscaro, devilhorns, cedric
> >
> > Reviewed By: cedric
> >
> > Subscribers: cedric, seoz, jpeg
> >
> > Differential Revision: https://phab.enlightenment.org/D4308
> >
> > Signed-off-by: Cedric BAIL 
> > ---
> >  src/lib/ecore_con/ecore_con.c | 15 +++
> >  src/lib/elput/elput_logind.c  | 14 +-
> >  2 files changed, 24 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/lib/ecore_con/ecore_con.c b/src/lib/ecore_con/ecore_con.c
> > index cc17fe8..cb66b27 100644
> > --- a/src/lib/ecore_con/ecore_con.c
> > +++ b/src/lib/ecore_con/ecore_con.c
> > @@ -4487,11 +4487,18 @@ _efl_net_ip_connect_async_run(void *data,
> > Ecore_Thread *thread EINA_UNUSED)
> >   * parameter must be a URL with schema, otherwise it won't
> >   * return anything.
> >   */
> > -char *url;
> > +Eina_Stringshare *url;
> >
> > -asprintf(, "%s://%s:%s", d->protocol == IPPROTO_UDP ? "udp" :
> > "tcp", host, port);
> > -proxies = ecore_con_libproxy_proxies_get(url);
> > -free(url);
> > +url = eina_stringshare_printf("%s://%s:%s", d->protocol ==
> > IPPROTO_UDP ? "udp" : "tcp", host, port);
> > +if (!url)
> > +  {
> > + ERR("Could not assemble URL");
> > +  }
> > +else
> > +  {
> > + proxies = ecore_con_libproxy_proxies_get(url);
> > + eina_stringshare_del(url);
> > +  }
> 
> why are you using stringshare here?
> 
>  - this is used only once, share makes no benefit.
> 
>  - this is used from thread, not sure eina stringshare is thread safe.
> 
> if it's complaining about asprintf() on some weirdo platform, we can
> malloc + memcpy the pieces

last i knew asnprintf is "not portable" like strdupa. alloca is about the only
thing we can trust to work. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Cedric BAIL]

On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
> On 19/09/16 23:33, Cedric BAIL wrote:
>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>>> against it.
>>
>> There was a thread weeks ago. You indeed didn't take part of that
>> discussion, but everyone else involved in that thread was ok. Actually
>> the discussion evolved more into a what else to merge in. So their was
>> an agreement before this email.
>
> Sorry, I missed that thread. What was the topic?

Merging eo, efl and ecore. Like in the title :-)

>>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>>> good thing. This makes our infrastructure easier to test.
>>
>> Please define "clean" as it is a bit abstract to me here. What I am
>> looking for here is the minimal set of component I need to have
>> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
>> you could do C without the C library, but would you ?
>
> You are right. Let's merge in Eina too.

That was kind of the discussion. Argument against merging eina, from
myself, is that we do have a lot of tool, just in tree, that do only
depends on eina and not on anything else.

> Or without joking: people have been using Eo without ecore and without
> Efl.Object. One example is Mike in E (reverted now because Eo was
> undeclared stable). You'll probably end up using Ecore in the same app,
> but again, everything you can say here you can say about Eina too.

Do we have any example of an application that use Eo without Ecore or
Efl today ?

> By "clean" I mean "isolated" or "untainted by its users up the stack".
> (see next comment for more info).
>
>> I think that your disagreement about merging is only and just because
>> you do not want to make asynchronous request a core feature of EFL.
>> The rest is mostly rhetoric. Could you please explain why you have so
>> much resistance to it being rolled into more place in efl ?
>
> That is exactly the reason (was I hiding it?), but not only, and one
> example of not "clean".
>
> A while back I was giving you some flack for not writing tests for a
> component of the EFL and cited Eo as an example of getting high test
> coverage. You then laughed it off and said something in the lines of
> "it's easier to test because it's smaller and not async" or something
> like that.
> **THAT IS EXACTLY MY POINT.**
>  From my experience (and I guess the industry's collective experience),
> having small separate units make quality assurance easier, units more
> testable (because you can easily unit test) and the code easier to maintain.

In my opinion there is a lot of code in Eo that is far from nice to
read and easy to maintain. First example is how intricate our pointer
infrastructure is in eo and how little it makes sense. I have to go
back at eina_safepointer, but there is seriously no justification for
that. Especially when it hasn't help us catch thread safety bugs for
example. So I agree with your small unit, but small unit has nothing
todo as per library, it has to do with how we divide things between
functions and files.

>> As for the tests, I really don't like our eo tests. They are not
>> really testing a clean scenario that is possible to guess, but just a
>> mismatch of everything into one big C file. When something break
>> there, you can't just rely on the name of the tests, or reading
>> quickly the code to guess what's happening. Nop. You have to get
>> hundred of lines of tests with little logical connection to each
>> other. I have found them less than useful when developping (And some
>> times buggy, as instead of testing a scenario that makes sense, they
>> were just testing that the code was matching the tests). So I don't
>> get your argument of making it easier to tests.
>
> The Eo suite is a mixture of success-scenario, failure-scenario and
> regression testing.
> Success scenario: making sure an expected scenario works.
> Failure scenario: making sure an expected scenario fails.
> regression testing: making sure what we have stays the same.
>
> Success scenarios would rarely need changing, only if you change
> something drastic or make the code more strict. Failure would need to
> change a bit more often, depending on how strict we make the code.
> Regression testing will probably change often, as they are there so you
> *understand* that you are changing behaviour, even if undocumented.
>
> I'm not aware of any buggy tests, but do let me know if you find one,
> and while at it, if possible, try and fix them.

The tests for hot event was completely backward and wrong. Don't worry
when I find a bugs I fix it.

> You have to also remember, these tests have been with us through a few
> Eo rewrites. They have been here from day 1. :)

They would benefit from some cleanup for sure and to be closer to an unit tests.

>>> If you mean just compile them together, then there's 

Re: [E-devel] Efl.Net and libproxy

[The Rasterman]

On Wed, 21 Sep 2016 11:29:00 -0300 Gustavo Sverzut Barbieri
 said:

> On Wed, Sep 21, 2016 at 9:08 AM, Carsten Haitzler 
> wrote:
> > On Tue, 20 Sep 2016 19:12:57 -0300 Gustavo Sverzut Barbieri
> >  said:
> >
> >> damn raster... I had to do so I could check.
> >>
> >> dlopen -> in git.
> >>
> >> server and libproxy.so wrapper, attached with the basics, I'm not
> >> doing all the cumbersome details to get a single process running and
> >> spawn it from libproxy.so wrapper without a race condition.
> >
> > there is no race.
> >
> > connect. if connect fail, spawn, set timer to connect every 0.1 sec until
> > successful.
> >
> > there is no race. first daemon spawned that binds to the socket wins. every
> > other one will fail and exit. there is no race to deal with as the bind does
> > the job for the daemon - first one in wins and the rest fail.
> 
> there is a problem with stale sockets. If daemon dies and leaves the
> socket file, then next daemons will try to bind and fail... then
> nobody wins. If we first unlink(), then there is a race.
> 
> Or should we use an abstract socket?

or ... never die. ever. once up, stay up (of course until session shuts down).
unless of course it's a crash/bug/segv in which case there is no unlink. :)

> >> I'd simplify all of that by using dbus with acquiring a name in the
> >> session bus and let that entity control it. Also would let the dbus
> >> daemon set isolation, like not inheriting current processes limits,
> >> namespaces and all.
> >
> > no it isn't any easier with dbus. see above. this is what efreetd does not.
> > its REALLyYsimple and race-free.
> 
> still doesn't address inheriting caps and other access controls...

efreetd doesnt need such caps. neither does this efl.proxy. remember how i
differentiated between "global resources" vs things like thumbnails where
thumbs are not global resources - they are directly tied tot he src file and
permissions on it and the permissions of the app etc.

a "proxy lookup" daemon is going to provide a global resource - the ability to
take an input target machine and give a resulting proxy server to use, and that
global resource may be as simple as an $http_proxy env var, or as complex as a
bunch of js in a pac file to execute to figure out which proxy to use.

> say constrained process A spawned the daemon. Then unconstrained
> process B will get the constraints.

in a constrained environment like one with SMACK this daemon would launch as
part of your login session. such constrained environments have to deal with
this. they could also set up systemd socket activation too. efreetd - same
story. outside of such env's the "i'll launch if i can't connect" just works
(tm).

> more concrete description is: for some reason "A" was started without
> network access. The daemon inherits that and thus libproxy won't work.
> That's okay, expected.

actually it'd still work because proxy daemon is doing a lookup locally as to
what to use. the app itself still does the connect and thus gets blocked. the
proxy daemon isnt meant to be doing dns lookups or anything else - just return
the $http_proxy to use or runt he js to figure out what proxy to use given a
nice fat bit of data in the pac file to choose what may be internal and/or
external sites by name/ip etc. and what proxy to use.

> However "B" has network access and is started afterwards, it will
> check and the daemon is there. It will use the daemon with libproxy
> that doesn't work due lack of network access. This is not expected.
> 
> I know not all systems employ fine grained capabilities and
> smack/selinux, but some do and we need to be careful.

such constrained environments have to launch the proxy daemon separately. as
above. as long as they either set up socket activation OR just launch it on
login everything works as normal.

> What I can do to solve this is to allow the server to be started from
> socket activation like systemd (also in --user variant). In that case,
> if the user cares about isolation, he uses the
> efl-proxy-resolver.socket and efl-proxy-resolver.service to start
> those on demand. The client will try to connect and it will work, thus
> it won't spawn any daemon on its own. Systemd will spawn the service
> with proper caps.

and everyone on bsd, windows, osx will hate you for doing this. tying to
systemd as the ONLY and DEFAULT method is stupid. you shot portability in the
foot.

the PORTABLE way that works on osx, windows (assuming local sockets work),
bsd's, solaris, linux and EVERY *nix is what i described. connect, if connect
fails, launch, then keep connecting until success.

"odd" constrained env's can simply avoid ever needing to trigger the "launch"
code by ensuring the daemon is already started OR use socket activation.
ecore_con/ipc already supported socket activation systemd stuff if the systemd
env vars were set to pass in the socket fd. all of that is/was already done...

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: protect against non-nul terminated string from mmap in filepreview

[The Rasterman]

On Wed, 21 Sep 2016 08:33:11 -0700 Cedric BAIL  said:

> On Sep 21, 2016 4:18 AM, "Carsten Haitzler"  wrote:
> >
> > raster pushed a commit to branch master.
> >
> >
> http://git.enlightenment.org/core/enlightenment.git/commit/?id=5861d9bef949c64cbc7ddad31b4ac2cc70bb6440
> >
> > commit 5861d9bef949c64cbc7ddad31b4ac2cc70bb6440
> > Author: Carsten Haitzler (Rasterman) 
> > Date:   Wed Sep 21 20:18:01 2016 +0900
> >
> > protect against non-nul terminated string from mmap in filepreview
> >
> > this should address 2nd gdb bt and fix T4543
> 
> No ! This patch is unnecessary or more exactly too late. Previous code was
> using the _n variant of append which call strlen. The current code only
> rely on the given length. Will revert.

why on earth is it doing strlen when obviously n bytes are to go in (or until
the nul byte)?

> > @fix
> > ---
> >  src/bin/e_widget_filepreview.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/bin/e_widget_filepreview.c
> b/src/bin/e_widget_filepreview.c
> > index 2602895..1f91073 100644
> > --- a/src/bin/e_widget_filepreview.c
> > +++ b/src/bin/e_widget_filepreview.c
> > @@ -931,8 +931,13 @@ _e_wid_fprev_preview_txt_map_success(void *data,
> Eio_File *handler EINA_UNUSED,
> > char *msg;
> > Evas_Coord mw, mh;
> >
> > +   msg = malloc(length + 1);
> > +   if (!msg) return;
> > +   strncpy(msg, map, length);
> > +   msg[length] = 0;
> > buf = eina_strbuf_new();
> > -   eina_strbuf_append_length(buf, map, length);
> > +   eina_strbuf_append_length(buf, msg, length);
> > +   free(msg);
> > msg = evas_textblock_text_utf8_to_markup(NULL,
> eina_strbuf_string_get(buf));
> > eina_strbuf_reset(buf);
> >
> >
> > --
> >
> >
> --
> ___
> 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


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: edje edje_embryo: use strncpy().

[The Rasterman]

On Wed, 21 Sep 2016 09:21:42 -0300 Gustavo Sverzut Barbieri
 said:

> On Wed, Sep 21, 2016 at 3:04 AM, ChunEon Park  wrote:
> > hermet pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=06bd8dcf330fe31891475c92aa340d4886f47e2b
> >
> > commit 06bd8dcf330fe31891475c92aa340d4886f47e2b
> > Author: Hermet Park 
> > Date:   Wed Sep 21 15:03:11 2016 +0900
> >
> > edje edje_embryo: use strncpy().
> >
> > This change is not meaningful but avoids an annoying coverity detection.
> > ---
> >  src/lib/edje/edje_embryo.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/lib/edje/edje_embryo.c b/src/lib/edje/edje_embryo.c
> > index bb46310..c09c3ff 100644
> > --- a/src/lib/edje/edje_embryo.c
> > +++ b/src/lib/edje/edje_embryo.c
> > @@ -1553,10 +1553,9 @@ _edje_embryo_fn_get_text(Embryo_Program *ep,
> > Embryo_Cell *params) }
> >  else
> >{
> > - char *ss;
> > -
> > - ss = alloca(strlen(s) + 1);
> > - strcpy(ss, s);
> > + int size = strlen(s) + 1;
> > + char *ss = alloca(size);
> > + strncpy(ss, s, size);
> 
> 
> strlcpy(), but really, just dismiss this one in covertity... is it
> dumb? We're alloca(strlen(s) + 1), how would it fail the size?
> 
> alternatively you can replace this with memcpy(ss, s, size), at least
> it's faster.

indeed. same here. dismiss such issues. just look at the code. the buffer is
the correct len. in fact size is wrong. it should be size - 1 or otherwise you
may get a non-0 byte terminated string... in fact it also is missing FORCING a
0 byte termination... so the code got no safer, but if you are going to be
paranoid, now you look at the code and go "well it's EXPECTING the string to
possibly not fit with strncpy .. but it isnt ensuring the 0 byte termination!".

sot he code actually became worse. before it was simple. the expectation it'd
fit was correct. it didnt need to do more. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: edje/edje_cc: use strncpy() instead of strcpy().

[The Rasterman]

On Wed, 21 Sep 2016 09:19:57 -0300 Gustavo Sverzut Barbieri
 said:

> On Wed, Sep 21, 2016 at 1:32 AM, ChunEon Park  wrote:
> > hermet pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=ab1a72f5e7df6fe0adef54bdcddd9867a2ebe3a6
> >
> > commit ab1a72f5e7df6fe0adef54bdcddd9867a2ebe3a6
> > Author: Hermet Park 
> > Date:   Wed Sep 21 13:30:44 2016 +0900
> >
> > edje/edje_cc: use strncpy() instead of strcpy().
> >
> > strncpy() is better for security.
> > Also, this change avoids annoying coverity detection.
> > ---
> >  src/bin/edje/edje_cc_parse.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/bin/edje/edje_cc_parse.c b/src/bin/edje/edje_cc_parse.c
> > index 525c71d..efabe22 100644
> > --- a/src/bin/edje/edje_cc_parse.c
> > +++ b/src/bin/edje/edje_cc_parse.c
> > @@ -391,7 +391,7 @@ next_token(char *p, char *end, char **new_p, int *delim)
> >   l = sscanf(tmpstr, "%*s %i \"%[^\"]\"", , fl);
> >   if (l == 2)
> > {
> > -  strcpy(file_buf, fl);
> > +  strncpy(file_buf, fl, sizeof(file_buf));
> >line = nm;
> >file_in = file_buf;
> > }
> 
> 
> the proper function to call is eina_strlcpy(), it will use strlcpy()
> if available, otherwise will ensure the nul byte.

actually the proper thing to do is... not change the code at all. read it. it's
safe. file_buf is 4096. fl is 4096. it CANNOT overflow by definition as the
string being copied into the target cannot be bigger.

people need to be careful of this kind of "well someone told me to use strncpy
because its safe". especially if it becomes a blindly applied "rule". read the
code. there is a chance you actually may break it by doing such changes (this
change doesn't).

in fact if there is an issue it's in the sscanf into the fl buffer which places
no limits on len (and fl is limited). of course ... the file path would have to
be insanely huge for this to happen and it'd be an invalid path in most
environments so things would fail one way or another... what edc files used to
exploit edje_cc? at this point we're compiling stuff so... all bets are off
anyway. so security isn't the issue imho.

anyway. point being - this code fixes NO BUG. it doesnt make code any safer.
what it does do is totally miss the actual potential bug in the sscanf :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/03: Revert "edje edje_cc_out: use strncpy()."

[Carsten Haitzler]

raster pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f4606d54eb2644a182a01aeef971fd53a0f53be9

commit f4606d54eb2644a182a01aeef971fd53a0f53be9
Author: Carsten Haitzler (Rasterman) 
Date:   Thu Sep 22 08:30:37 2016 +0900

Revert "edje edje_cc_out: use strncpy()."

This reverts commit 6de3b2c5d36993cf3dbe94e8fbefd04043f91740.

just dismiss in coverity if the code is not actually wrong
---
 src/bin/edje/edje_cc_out.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/bin/edje/edje_cc_out.c b/src/bin/edje/edje_cc_out.c
index cf9a831..90a8e41 100644
--- a/src/bin/edje/edje_cc_out.c
+++ b/src/bin/edje/edje_cc_out.c
@@ -4036,10 +4036,9 @@ data_process_string(Edje_Part_Collection *pc, const char 
*prefix, char *s, void
int quote, escape;
 
keyl = strlen(prefix) + 2;
-   int key_len = keyl + 1;
-   key = alloca(key_len);
+   key = alloca(keyl + 1);
if (!key) return;
-   strncpy(key, prefix, key_len);
+   strcpy(key, prefix);
strcat(key, ":\"");
quote = 0;
escape = 0;

-- 

[EGIT] [core/efl] master 02/03: Revert "edje edje_embryo: use strncpy()."

[Carsten Haitzler]

raster pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=8c28a70b4373d15dca8333dbd0d9a314dd941505

commit 8c28a70b4373d15dca8333dbd0d9a314dd941505
Author: Carsten Haitzler (Rasterman) 
Date:   Thu Sep 22 08:31:00 2016 +0900

Revert "edje edje_embryo: use strncpy()."

This reverts commit 06bd8dcf330fe31891475c92aa340d4886f47e2b.

just dismiss in coverity if the code is not actually wrong
---
 src/lib/edje/edje_embryo.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/lib/edje/edje_embryo.c b/src/lib/edje/edje_embryo.c
index c09c3ff..bb46310 100644
--- a/src/lib/edje/edje_embryo.c
+++ b/src/lib/edje/edje_embryo.c
@@ -1553,9 +1553,10 @@ _edje_embryo_fn_get_text(Embryo_Program *ep, Embryo_Cell 
*params)
   }
 else
   {
- int size = strlen(s) + 1;
- char *ss = alloca(size);
- strncpy(ss, s, size);
+ char *ss;
+
+ ss = alloca(strlen(s) + 1);
+ strcpy(ss, s);
  ss[params[3] - 1] = 0;
  SETSTR(ss, params[2]);
   }

-- 

[EGIT] [core/efl] master 03/03: Revert "edje/edje_cc: use strncpy() instead of strcpy()."

[Carsten Haitzler]

raster pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=53095d6fc76bad3293cfbf493684e82a29811d8b

commit 53095d6fc76bad3293cfbf493684e82a29811d8b
Author: Carsten Haitzler (Rasterman) 
Date:   Thu Sep 22 08:31:04 2016 +0900

Revert "edje/edje_cc: use strncpy() instead of strcpy()."

This reverts commit ab1a72f5e7df6fe0adef54bdcddd9867a2ebe3a6.

just dismiss in coverity if the code is not actually wrong
---
 src/bin/edje/edje_cc_parse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/edje/edje_cc_parse.c b/src/bin/edje/edje_cc_parse.c
index efabe22..525c71d 100644
--- a/src/bin/edje/edje_cc_parse.c
+++ b/src/bin/edje/edje_cc_parse.c
@@ -391,7 +391,7 @@ next_token(char *p, char *end, char **new_p, int *delim)
  l = sscanf(tmpstr, "%*s %i \"%[^\"]\"", , fl);
  if (l == 2)
{
-  strncpy(file_buf, fl, sizeof(file_buf));
+  strcpy(file_buf, fl);
   line = nm;
   file_in = file_buf;
}

-- 

[EGIT] [core/efl] master 01/01: ecore, ecore_con: simplify destructor by linking future life cycle with object.

[Cedric BAIL]

cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=72f0bfa2248b8e6595985827b042d94acc50bc76

commit 72f0bfa2248b8e6595985827b042d94acc50bc76
Author: Cedric BAIL 
Date:   Wed Sep 21 16:19:26 2016 -0700

ecore,ecore_con: simplify destructor by linking future life cycle with 
object.
---
 src/lib/ecore/efl_io_copier.c|  4 +---
 src/lib/ecore_con/efl_net_dialer_tcp.c   |  6 +-
 src/lib/ecore_con/efl_net_dialer_websocket.c | 13 ++---
 3 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/src/lib/ecore/efl_io_copier.c b/src/lib/ecore/efl_io_copier.c
index ad9a38a..1f571c8 100644
--- a/src/lib/ecore/efl_io_copier.c
+++ b/src/lib/ecore/efl_io_copier.c
@@ -104,6 +104,7 @@ _efl_io_copier_job_schedule(Eo *o, Efl_Io_Copier_Data *pd)
 
efl_future_use(>job, efl_loop_job(efl_loop_user_loop_get(o), o));
efl_future_then(pd->job, _efl_io_copier_job, NULL, NULL, o);
+   efl_future_link(o, pd->job);
 }
 
 /* NOTE: the returned slice may be smaller than requested since the
@@ -690,9 +691,6 @@ _efl_io_copier_efl_object_destructor(Eo *o, 
Efl_Io_Copier_Data *pd)
efl_io_copier_source_set(o, NULL);
efl_io_copier_destination_set(o, NULL);
 
-   if (pd->job)
- efl_future_cancel(pd->job);
-
efl_destructor(efl_super(o, MY_CLASS));
 
if (pd->buf)
diff --git a/src/lib/ecore_con/efl_net_dialer_tcp.c 
b/src/lib/ecore_con/efl_net_dialer_tcp.c
index c114d4d..b490aaa 100644
--- a/src/lib/ecore_con/efl_net_dialer_tcp.c
+++ b/src/lib/ecore_con/efl_net_dialer_tcp.c
@@ -60,9 +60,6 @@ _efl_net_dialer_tcp_efl_object_destructor(Eo *o, 
Efl_Net_Dialer_Tcp_Data *pd)
(!efl_io_closer_closed_get(o)))
  efl_io_closer_close(o);
 
-   if (pd->connect.timeout)
- efl_future_cancel(pd->connect.timeout);
-
if (pd->connect.thread)
  {
 ecore_thread_cancel(pd->connect.thread);
@@ -82,8 +79,6 @@ _efl_net_dialer_tcp_connect_timeout(void *data, const 
Efl_Event *ev EINA_UNUSED)
Efl_Net_Dialer_Tcp_Data *pd = efl_data_scope_get(o, MY_CLASS);
Eina_Error err = ETIMEDOUT;
 
-   pd->connect.timeout = NULL;
-
if (pd->connect.thread)
  {
 ecore_thread_cancel(pd->connect.thread);
@@ -175,6 +170,7 @@ _efl_net_dialer_tcp_efl_net_dialer_dial(Eo *o, 
Efl_Net_Dialer_Tcp_Data *pd EINA_
  {
 efl_future_use(>connect.timeout, 
efl_loop_timeout(efl_loop_user_loop_get(o), pd->timeout_dial, o));
 efl_future_then(pd->connect.timeout, 
_efl_net_dialer_tcp_connect_timeout, NULL, NULL, o);
+efl_future_link(o, pd->connect.timeout);
  }
 
return 0;
diff --git a/src/lib/ecore_con/efl_net_dialer_websocket.c 
b/src/lib/ecore_con/efl_net_dialer_websocket.c
index fb126dd..52c0661 100644
--- a/src/lib/ecore_con/efl_net_dialer_websocket.c
+++ b/src/lib/ecore_con/efl_net_dialer_websocket.c
@@ -740,8 +740,6 @@ _efl_net_dialer_websocket_job(void *data, const Efl_Event 
*ev EINA_UNUSED)
Eo *o = data;
Efl_Net_Dialer_Websocket_Data *pd = efl_data_scope_get(o, MY_CLASS);
 
-   pd->job = NULL;
-
efl_ref(o);
 
if (efl_io_reader_can_read_get(pd->http))
@@ -767,6 +765,7 @@ _efl_net_dialer_websocket_job_schedule(Eo *o, 
Efl_Net_Dialer_Websocket_Data *pd)
if (!loop) return;
efl_future_use(>job, efl_loop_job(loop, o));
efl_future_then(pd->job, _efl_net_dialer_websocket_job, NULL, NULL, o);
+   efl_future_link(o, pd->job);
 }
 
 static void
@@ -962,18 +961,9 @@ _efl_net_dialer_websocket_efl_object_destructor(Eo *o, 
Efl_Net_Dialer_Websocket_
 
efl_event_callback_array_del(pd->http, 
_efl_net_dialer_websocket_http_cbs(), o);
 
-   if (pd->close_timeout)
- efl_future_cancel(pd->close_timeout);
-
efl_del(pd->http);
pd->http = NULL;
 
-   if (pd->job)
- {
-efl_future_cancel(pd->job);
-pd->job = NULL;
- }
-
efl_destructor(efl_super(o, MY_CLASS));
 
eina_stringshare_replace(>address_dial, NULL);
@@ -1511,6 +1501,7 @@ _efl_net_dialer_websocket_close_request(Eo *o, 
Efl_Net_Dialer_Websocket_Data *pd
 
efl_future_use(>close_timeout, 
efl_loop_timeout(efl_loop_user_loop_get(o), 2.0, o));
efl_future_then(pd->close_timeout, 
_efl_net_dialer_websocket_close_request_timeout, NULL, NULL, o);
+   efl_future_link(o, pd->close_timeout);
 
efl_io_writer_can_write_set(o, EINA_FALSE);
 

-- 

Re: [E-devel] EFL interface, what's left to be done

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen  wrote:
> On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
>> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
>> [...]
 promise/future should be first-class citizen... as well as iterator
 and the likes. There is a start already, but refinement is really
 needed, like returning an iterator should handle warn_unused, free,
 own... Promise should have its own callback signature, simplified for
 the user.

>>>
>>> They can, be, but they will just be provided by Eo. There's no need for
>>> any special treatment in Eo.
>>>
>>> Promise signature: you don't need to do it in Eo. I mean, you can add a
>>> special type in Eolian, but Eo itself need not be aware. Also, I disagree.
>>
>> Do you mean still use Eo's events to dispatch promises?
>
> Not necessarily, just use the same signature because it's a good one,
> it's extendable, it applies here too, and it's easier for bindings this way.

It's a good one to who? It's a generic one, for sure, but that doesn't
make it a good one. Promises, for instance, will carry a value, but
it's not immediately available. Even for regular events I don't get
why the object must be fetched from the efl_event...



>> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
>> now hints of benefits. Asking Cedric leads me to an awful answer...
>> :-/
>>
>> The promise thing should only be a thin layer that forces a clear
>> pattern: wait for data, deliver data or call failure. I don't get why
>> in the other thread people were talking about references in promises,
>> inheritance, etc.
>>
>
> Not sure about inheritance, but you need references for lifecycle. It's
> even better when you have automatic lifecycle control, so when an object
> dies, the associated promise dies too.

the lifecycle of a promise is simple and there should be no refs on
it. OTOH, if it's returned by an object, then the object indeed should
cancel all its promises. But it must know that already, after all it
must deliver a value sooner or later.

IOW: Eo should know about promises, promises shouldn't know about
eo... or at least don't need to.



 AND if possible, make eolian or a new tool to handle connections for
 us, if it was easy to declare objects with composition of
 events/promises, it would save us lots of typing and errors.


>>>
>>> I'm not sure what you meant here.
>>
>> the process of creating and object, setting its properties and
>> connecting events is painful in C. We need to replicate the whole
>> "_${METHOD}(efl_added, ${VALUE})"... for events it's even
>> worse.
>>
>> While the API is what it should be, it's PITA to use. If we could
>> extend the generator to do those for us, we'd have to implement only
>> high level functions. Like it does for C++ or Lua bindings, do to C
>> "user code" (could also do C++/Lua user code as well). Example:
>>
>> myapp.eou:  # eou = eo user
>>
>> objects {
>> xpto { /* creates an object called "xpto" */
>>children {
>>   window { /* window is part of xpto, it will be created using
>> given type and properties */
>>  type: Efl.Ui.Win;
>>  constructor {
>> type: Efl.Ui.Win.Type.basic;
>> title: "hello world";
>>  }
>>  events { /* these will be connected for you, callback
>> handlers are expanded based on event payload */
>> resized @proxy; /* proxy = will forward this event as
>> "xpto" using the same name */
>> delete,request; /* user must implement the callback
>> with handler */
>>  }
>>   }
>>   box {
>>  type: Efl.Ui.Box;
>>   }
>>   label1 {
>>  type: Efl.Ui.Label;
>>   }
>>   label2 {
>>  type: Efl.Ui.Label;
>>   }
>>   entry {
>>  type: Efl.Ui.Entry;
>>   }
>>   }
>>
>>connections {
>>   entry: changed -> label2: text.set; /* somehow like Qt's
>> signal connection */
>>}
>>
>>composition { /* basic method calls using other objects and constants 
>> */
>>box.pack_align(0.5, 0.5);
>>
>>label1.hint_align.set(0.0, 0.0);
>>box.pack(label1);
>>
>>label2.hint_align.set(1.0, 1.0);
>>box.pack(label2);
>>box.pack(entry);
>>  }
>> }
>> }
>>
>>
>> Then in my code I'd just:
>>
>> #include "myapp.eou.h"
>>
>> static void _xpto_window_delete_request(Eo *xpto, Eo *window) /*
>> nothing else as there is no payload in that event */
>> {
>> printf("window was closed\n");
>> }
>>
>> static void _xpto_resized(void *data, const Efl_Event *event) // or we
>> create an xpto_event_resized_add() which unpacks and makes it easier
>> to use
>> {
>> }
>>
>> int main() {
>>  // ...
>>
>>  Eo *xpto = xpto_new();
>>  

[E-devel] Edi 0.4.0

[Andrew Williams]

Following 1.18 I released Edi 0.4 - but I forgot to upload to our download
site. Would someone please be able to add the download from
https://github.com/ajwillia-ms/edi/releases/tag/v0.4.0 to our download site?

Thanks so much.

For the curious here is the changelog:

Features:
• Auto-detected build provider for project
• Filter file list based on ignored build files
• Allow filtering of file list using regular expressions
• Display build errors inline in editor
• Support opening a single file
Bug fixes:
• Fix some missing icons
• Fix about and settings window attributes
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/enlightenment] master 02/02: NULL out xwayland fd handlers after deleting them

[Derek Foreman]

derekf pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=22a99c5b5a2a0d93a0fb5f1e7364055e2ecbc613

commit 22a99c5b5a2a0d93a0fb5f1e7364055e2ecbc613
Author: Derek Foreman 
Date:   Wed Sep 21 16:45:04 2016 -0500

NULL out xwayland fd handlers after deleting them

This fixes a valgrind error that can happen when we accidentally
free these again later because they still had non-NULL values.
---
 src/modules/xwayland/e_mod_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/modules/xwayland/e_mod_main.c 
b/src/modules/xwayland/e_mod_main.c
index f19fee3..f8eb1f5 100644
--- a/src/modules/xwayland/e_mod_main.c
+++ b/src/modules/xwayland/e_mod_main.c
@@ -247,6 +247,8 @@ fail:
   ecore_main_fd_handler_del(exs->abs_hdlr);
 if (exs->unx_hdlr)
   ecore_main_fd_handler_del(exs->unx_hdlr);
+exs->abs_hdlr = NULL;
+exs->unx_hdlr = NULL;
 break;
   case -1:
 ERR("Failed to fork: %m");

-- 

[EGIT] [core/enlightenment] master 01/02: Don't kill self during shutdown

[Derek Foreman]

derekf pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=494f76b0ab7f5b2c51ab7721a3f5c34750e0fef0

commit 494f76b0ab7f5b2c51ab7721a3f5c34750e0fef0
Author: Derek Foreman 
Date:   Wed Sep 21 16:42:31 2016 -0500

Don't kill self during shutdown

When Xwayland is running we end up with a client with the same pid
as the compositor in the client list.  We need to avoid killing that
client, as it will interrupt the proper shutdown procedure.

fix T4439
---
 src/bin/e_client.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/bin/e_client.c b/src/bin/e_client.c
index 20d18ac..a09680e 100644
--- a/src/bin/e_client.c
+++ b/src/bin/e_client.c
@@ -4578,6 +4578,7 @@ e_client_act_kill_begin(E_Client *ec)
if (!ec->zone) return;
if (ec->internal) return;
if (ec->lock_close) return;
+   if (ec->netwm.pid == getpid()) return;
if ((ec->netwm.pid > 1) && (e_config->kill_process))
  {
 kill(ec->netwm.pid, SIGINT);

-- 

[EGIT] [tools/enventor] master 01/01: Adding slovenian translation

[maxerba]

maxerba pushed a commit to branch master.

http://git.enlightenment.org/tools/enventor.git/commit/?id=99a5df42483e5f78a49cb4f01c3fe1472a29d5d7

commit 99a5df42483e5f78a49cb4f01c3fe1472a29d5d7
Author: maxerba 
Date:   Wed Sep 21 22:25:59 2016 +0200

Adding slovenian translation
---
 po/LINGUAS |   2 +-
 po/sl.po   | 423 +
 2 files changed, 424 insertions(+), 1 deletion(-)

diff --git a/po/LINGUAS b/po/LINGUAS
index 6409b02..efa1d40 100644
--- a/po/LINGUAS
+++ b/po/LINGUAS
@@ -1 +1 @@
-en ru
+en sl ru
diff --git a/po/sl.po b/po/sl.po
new file mode 100644
index 000..484cd53
--- /dev/null
+++ b/po/sl.po
@@ -0,0 +1,423 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR Enventor development team
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR , YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: enventor 0.9.0\n"
+"Report-Msgid-Bugs-To: enlightenment-devel@lists.sourceforge.net\n"
+"POT-Creation-Date: 2016-09-19 14:56+0200\n"
+"PO-Revision-Date: 2016-09-21 17:09+0200\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Poedit 1.8.9\n"
+"Last-Translator: Renato Rener \n"
+"Plural-Forms: nplurals=4; plural=(n%100==1 ? 0 : n%100==2 ? 1 : n%100==3 "
+"|| n%100==4 ? 2 : 3);\n"
+"Language: sl_SI\n"
+
+#: src/bin/base_gui.c:67
+#, c-format
+msgid "%s - Enventor"
+msgstr "%s - Enventor"
+
+#: src/bin/config_data.c:72
+msgid "Failed to generate tmp folder!"
+msgstr "Neuspeh pri ustvarjanju začasne mape!"
+
+#: src/bin/config_data.c:91 src/bin/config_data.c:104
+#, c-format
+msgid "Cannot create a config folder \"%s\""
+msgstr "Ne morem ustvariti nastavitvene mape \"%s\""
+
+#: src/bin/config_data.c:115
+#, c-format
+msgid "Cannot save a config file \"%s\""
+msgstr "Ne morem shraniti nastavitvene datoteke \"%s\""
+
+#: src/bin/config_data.c:157
+#, c-format
+msgid "Cannot load a config file \"%s\""
+msgstr "Ne morem naložiti nastavitvene datoteke \"%s\""
+
+#: src/bin/config_data.c:165 src/bin/file_mgr.c:193 src/bin/goto.c:136
+#: src/bin/menu.c:613 src/bin/newfile.c:144 src/bin/panes.c:321
+#: src/bin/search.c:337 src/bin/setting.c:187 src/bin/statusbar.c:312
+#: src/bin/text_setting.c:405 src/bin/text_setting.c:456
+#: src/bin/text_setting.c:487 src/bin/text_setting.c:956 src/bin/tools.c:186
+msgid "Failed to allocate Memory!"
+msgstr "Dodeljevanje spomina spodletelo!"
+
+#: src/bin/file_mgr.c:71
+msgid "EDC has been changed on the file system."
+msgstr "EDC je bil spremenjen na datotečnem sistemu."
+
+#: src/bin/file_mgr.c:73
+msgid "Do you want to replace the contents?"
+msgstr "Ali želite zamenjati vsebino?"
+
+#: src/bin/file_mgr.c:84
+msgid "Save As"
+msgstr "Shrani kot"
+
+#: src/bin/file_mgr.c:92 src/bin/search.c:407
+msgid "Replace"
+msgstr "Zamenjaj"
+
+#: src/bin/file_mgr.c:98
+msgid "Ignore"
+msgstr "Spreglej"
+
+#: src/bin/file_mgr.c:157
+#, c-format
+msgid "File saved. \"%s\""
+msgstr "Datoteka shranjena. \"%s\""
+
+#: src/bin/file_mgr.c:159
+#, c-format
+msgid "Already saved. \"%s\""
+msgstr "Že shranjeno. \"%s\""
+
+#: src/bin/goto.c:93
+msgid "Invalid line number"
+msgstr "Napačno število vrstice"
+
+#: src/bin/goto.c:142
+msgid "Enventor Goto Line"
+msgstr "Enventor Skoči na vrstico"
+
+#: src/bin/goto.c:146
+msgid "Go to Line"
+msgstr "Skoči na vrstico"
+
+#: src/bin/goto.c:168
+#, c-format
+msgid "Enter line number [1..%d]:"
+msgstr "Vnesi vrstico številka [1..%d]:"
+
+#: src/bin/goto.c:192 src/bin/menu.c:150
+msgid "Ok"
+msgstr "V Redu"
+
+#: src/bin/goto.c:204 src/bin/search.c:429
+msgid "Failed to grab key - Escape"
+msgstr "Zajetje tipke Esc spodletelo"
+
+#: src/bin/live_edit.c:1983 src/bin/live_edit.c:2028 src/bin/live_edit.c:2030
+#: src/bin/main.c:851 src/lib/auto_comp.c:369 src/lib/ctxpopup.c:766
+#, c-format
+msgid "Failed to grab key - %s"
+msgstr "Zajetje znaka spodletelo - %s"
+
+#: src/bin/live_edit.c:2091
+msgid ""
+"Double click part to confirm. (Esc = cancel, Direction Key = move item per "
+"pixel, Ctrl = disable auto-aligning)"
+msgstr ""
+"Dvoklikni del za potrditev. (Esc = preklic, Smerna tipka = premikanje en "
+"predmet na piksel, Ctrl = onemogoči samodejno poravnavo)"
+
+#: src/bin/live_edit.c:2247
+msgid "Faild to allocate Memory!"
+msgstr "Dodeljevanje spomina spodletelo!"
+
+#: src/bin/main.c:24
+msgid "Auto Completion Enabled."
+msgstr "Samodokončanje omogočeno."
+
+#: src/bin/main.c:25
+msgid "Auto Completion Disabled."
+msgstr "Samodokončanje onemogočeno."
+
+#: src/bin/main.c:34
+msgid "Auto Indentation Enabled."
+msgstr "Samozamik omogočen."
+
+#: src/bin/main.c:35
+msgid "Auto Indentation Disabled."
+msgstr "Samozamik onemogočen."
+
+#: src/bin/main.c:207
+#, c-format
+msgid "Font Size: %1.1fx"
+msgstr "Velikost pisave: %1.1fx"
+
+#: src/bin/menu.c:137
+msgid "New File: Choose a template"
+msgstr "Nova 

[EGIT] [core/enlightenment] master 01/01: update wayland readme for gl-drm

[Christopher Michael]

devilhorns pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=cbd55b9137a26618880dada7775583aff0a4d8cf

commit cbd55b9137a26618880dada7775583aff0a4d8cf
Author: Chris Michael 
Date:   Wed Sep 21 16:05:27 2016 -0400

update wayland readme for gl-drm

Signed-off-by: Chris Michael 
---
 README.wayland | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.wayland b/README.wayland
index da0be0b..08f88d3 100644
--- a/README.wayland
+++ b/README.wayland
@@ -16,6 +16,7 @@ Wayland support.
 Firstly, you MUST have EFL built with the following options:
 
   --enable-drm
+  --enable-gl-drm (for hardware acceleration)
   --enable-wayland
   --enable-systemd
   --enable-elput

-- 

[EGIT] [apps/terminology] master 01/01: Forgot to git add the new translation :)

[Massimo Maiurana]

maxerba pushed a commit to branch master.

http://git.enlightenment.org/apps/terminology.git/commit/?id=85dbaf83d69c6761bfb7b2ce2fb1ce0229429647

commit 85dbaf83d69c6761bfb7b2ce2fb1ce0229429647
Author: maxerba 
Date:   Wed Sep 21 21:57:14 2016 +0200

Forgot to git add the new translation :)
---
 po/sl.po | 922 +++
 1 file changed, 922 insertions(+)

diff --git a/po/sl.po b/po/sl.po
new file mode 100644
index 000..f629b60
--- /dev/null
+++ b/po/sl.po
@@ -0,0 +1,922 @@
+# Slovenian translation for enlightenment
+# Copyright (c) 2016 Rosetta Contributors and Canonical Ltd 2016
+# This file is distributed under the same license as the enlightenment package.
+# FIRST AUTHOR , 2016.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: enlightenment\n"
+"Report-Msgid-Bugs-To: FULL NAME \n"
+"POT-Creation-Date: 2016-06-21 23:40+0200\n"
+"PO-Revision-Date: 2016-09-21 17:18+0200\n"
+"Last-Translator: Renato Rener \n"
+"Language-Team: Slovenian \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Launchpad-Export-Date: 2016-09-16 20:20+\n"
+"X-Generator: Poedit 1.8.9\n"
+"Language: sl\n"
+
+#: src/bin/controls.c:253
+msgid "Controls"
+msgstr "Nadzor"
+
+#: src/bin/controls.c:269
+msgid "New"
+msgstr "Nov"
+
+#: src/bin/controls.c:275
+msgid "Split V"
+msgstr "Razdeli N"
+
+#: src/bin/controls.c:277
+msgid "Split H"
+msgstr "Split V"
+
+#: src/bin/controls.c:283
+msgid "Miniview"
+msgstr "Mini pogled"
+
+#: src/bin/controls.c:289 src/bin/win.c:3275
+msgid "Set title"
+msgstr "Nastavi ime"
+
+#: src/bin/controls.c:299 src/bin/termio.c:959 src/bin/termio.c:4085
+msgid "Copy"
+msgstr "Kopiraj"
+
+#: src/bin/controls.c:305
+msgid "Paste"
+msgstr "Prilepi"
+
+#: src/bin/controls.c:311
+msgid "Settings"
+msgstr "Nastavitve"
+
+#: src/bin/controls.c:317
+msgid "About"
+msgstr "O programu"
+
+#: src/bin/controls.c:327
+msgid "Close Terminal"
+msgstr "Zapri terminal"
+
+#: src/bin/about.c:56
+#, c-format
+msgid ""
+"Terminology %sWhy should terminals be boring?This "
+"terminal was written for Enlightenment, to use EFL and otherwise push the "
+"boundaries of what a modern terminal emulator should be. We hope you enjoy "
+"it.Copyright © 2012-%d by:%sDistributed under the 2-"
+"clause BSD license detailed below:%s"
+msgstr ""
+"Terminology %sZakaj bi morali biti terminali dolgočasni?"
+"Tale terminal je bil napisan za Enlightenment, da uporablja EFL in "
+"premakne meje tega, kakšen bi moral moderen terminalski posnemovalnik biti. "
+"Upamo da boste uživali z njim.Copyright © 2012-%d by:"
+"%sRazdeljuje se pod 2-klavzulo BSD licence podrobneje spodaj:"
+"%s"
+
+#: src/bin/keyin.c:633
+msgid "Scrolling"
+msgstr "Drsenje"
+
+#: src/bin/keyin.c:634
+msgid "Scroll one page up"
+msgstr "Zadrsaj za eno stran navzgor"
+
+#: src/bin/keyin.c:635
+msgid "Scroll one page down"
+msgstr "Zadrsaj za eno stran navzdol"
+
+#: src/bin/keyin.c:636
+msgid "Scroll one line up"
+msgstr "Zadrsaj za eno vrstico navzgor"
+
+#: src/bin/keyin.c:637
+msgid "Scroll one line down"
+msgstr "Zadrsaj za eno vrstico navzdol"
+
+#: src/bin/keyin.c:638
+msgid "Go to the top of the backlog"
+msgstr "Pojdi na vrh dnevnika"
+
+#: src/bin/keyin.c:639
+msgid "Reset scroll"
+msgstr "Ponovno zaženi drsenje"
+
+#: src/bin/keyin.c:641
+msgid "Copy/Paste"
+msgstr "Kopiraj/Prilepi"
+
+#: src/bin/keyin.c:642
+msgid "Copy selection to Primary buffer"
+msgstr "Kopiraj izbrano v primarni predpomnilnik"
+
+#: src/bin/keyin.c:643
+msgid "Copy selection to Clipboard buffer"
+msgstr "Kopiraj izbrano v predpomnilnik odložišča"
+
+#: src/bin/keyin.c:644
+msgid "Paste Primary buffer (highlight)"
+msgstr "Primarni predpomnilnik (označeno)"
+
+#: src/bin/keyin.c:645
+msgid "Paste Clipboard buffer (ctrl+c/v)"
+msgstr "Predpomnilnik Prilepljanja iz odložišča (ctrl+c/v)"
+
+#: src/bin/keyin.c:647
+msgid "Splits/Tabs"
+msgstr "Razdelitve/Zavihki"
+
+#: src/bin/keyin.c:648
+msgid "Focus to the previous terminal"
+msgstr "Fokusiraj se na prejšnji terminal"
+
+#: src/bin/keyin.c:649
+msgid "Focus to the next terminal"
+msgstr "Fokusiraj se na naslednji terminal"
+
+#: src/bin/keyin.c:650
+msgid "Split horizontally (new below)"
+msgstr "Razdeli vodoravno (nov spodaj)"
+
+#: src/bin/keyin.c:651
+msgid "Split vertically (new on right)"
+msgstr "Razdeli navpično (nov desno)"
+
+#: src/bin/keyin.c:652
+msgid "Create a new \"tab\""
+msgstr "Ustvari nov zavihek"
+
+#: src/bin/keyin.c:653
+msgid "Close the focused terminal"
+msgstr "Zapri terminal v fokusu"
+
+#: src/bin/keyin.c:654
+msgid "Bring up \"tab\" switcher"
+msgstr "Dvigni preklopnik \"zavihka\""
+
+#: src/bin/keyin.c:655
+msgid "Switch to terminal tab 1"
+msgstr "Preklopi na terminalov 1. zavihek"
+
+#: src/bin/keyin.c:656
+msgid "Switch to terminal tab 2"
+msgstr "Preklopi na terminalov 2. zavihek"
+
+#: src/bin/keyin.c:657

[EGIT] [apps/terminology] master 01/01: Adding slovenian translation

[Massimo Maiurana]

maxerba pushed a commit to branch master.

http://git.enlightenment.org/apps/terminology.git/commit/?id=d12fee27ed9192b93800045460e8c806c75a6345

commit d12fee27ed9192b93800045460e8c806c75a6345
Author: maxerba 
Date:   Wed Sep 21 21:56:11 2016 +0200

Adding slovenian translation
---
 po/LINGUAS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/po/LINGUAS b/po/LINGUAS
index 33e375f..cfc6ed7 100644
--- a/po/LINGUAS
+++ b/po/LINGUAS
@@ -1 +1 @@
-ca de el eo es fi fr hi it ko ms sr tr vi
+ca de el eo es fi fr hi it ko ms sl sr tr vi

-- 

[EGIT] [apps/ephoto] master 01/01: Adding slovenian translation

[maxerba]

maxerba pushed a commit to branch master.

http://git.enlightenment.org/apps/ephoto.git/commit/?id=948d40643dd77ab494e6ef6014ad866f6e026937

commit 948d40643dd77ab494e6ef6014ad866f6e026937
Author: maxerba 
Date:   Wed Sep 21 21:45:11 2016 +0200

Adding slovenian translation
---
 po/LINGUAS |   1 +
 po/sl.po   | 641 +
 2 files changed, 642 insertions(+)

diff --git a/po/LINGUAS b/po/LINGUAS
index 7398210..ae6c447 100644
--- a/po/LINGUAS
+++ b/po/LINGUAS
@@ -1,4 +1,5 @@
 cs
 de
 it
+sl
 sk
diff --git a/po/sl.po b/po/sl.po
new file mode 100644
index 000..933ac01
--- /dev/null
+++ b/po/sl.po
@@ -0,0 +1,641 @@
+# Slovenian translation for enlightenment
+# Copyright (c) 2016 Rosetta Contributors and Canonical Ltd 2016
+# This file is distributed under the same license as the enlightenment package.
+# FIRST AUTHOR , 2016.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: enlightenment e-photo\n"
+"Report-Msgid-Bugs-To: FULL NAME \n"
+"POT-Creation-Date: 2016-08-30 20:00+0200\n"
+"PO-Revision-Date: 2016-09-21 17:16+0200\n"
+"Last-Translator: Renato Rener \n"
+"Language-Team: Slovenian \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=4; plural=(n%100==1 ? 0 : n%100==2 ? 1 : n%100==3 || n"
+"%100==4 ? 2 : 3);\n"
+"X-Launchpad-Export-Date: 2016-09-15 11:00+\n"
+"X-Generator: Poedit 1.8.9\n"
+"Language: sl\n"
+
+#: src/bin/ephoto_bcg.c:346 src/bin/ephoto_single_browser.c:1776
+msgid "Brightness/Contrast/Gamma"
+msgstr "Svetlost/Ostrina/Barva"
+
+#: src/bin/ephoto_bcg.c:352
+msgid "Gamma"
+msgstr "Barva"
+
+#: src/bin/ephoto_bcg.c:366
+msgid "Contrast"
+msgstr "Ostrina"
+
+#: src/bin/ephoto_bcg.c:380
+msgid "Brightness"
+msgstr "Svetlost"
+
+#: src/bin/ephoto_config.c:29 src/bin/ephoto_config.c:137
+msgid "Root Directory"
+msgstr "Korenska mapa"
+
+#: src/bin/ephoto_config.c:31 src/bin/ephoto_config.c:139
+msgid "Home Directory"
+msgstr "Domača mapa"
+
+#: src/bin/ephoto_config.c:33 src/bin/ephoto_config.c:141
+msgid "Last Open Directory"
+msgstr "Zadnja odprta mapa"
+
+#: src/bin/ephoto_config.c:73 src/bin/ephoto_config.c:143
+#: src/bin/ephoto_config.c:157
+msgid "Custom Directory"
+msgstr "Mapa po meri"
+
+#: src/bin/ephoto_config.c:85
+msgid "General"
+msgstr "Splošno"
+
+#: src/bin/ephoto_config.c:98
+msgid "Show Folders On Start"
+msgstr "Prikaži mape ob zagonu"
+
+#: src/bin/ephoto_config.c:106
+msgid "Prompt Before Changing The Filesystem"
+msgstr "Vprašaj pred spreminjanjem datotečnega sistema"
+
+#: src/bin/ephoto_config.c:114
+msgid "Move Files When Dropped"
+msgstr "Premakni datoteke ob spuščanju"
+
+#: src/bin/ephoto_config.c:122
+msgid "Smooth Scale Images"
+msgstr "Mehki prehodi slike"
+
+#: src/bin/ephoto_config.c:130
+msgid "Top Level Directory"
+msgstr "Mapa vrhnjega nivoja"
+
+#: src/bin/ephoto_config.c:182
+msgid "second"
+msgid_plural "seconds"
+msgstr[0] ""
+msgstr[1] ""
+msgstr[2] ""
+msgstr[3] ""
+
+#: src/bin/ephoto_config.c:221 src/bin/ephoto_main.c:611
+#: src/bin/ephoto_main.c:614
+msgid "Slideshow"
+msgstr "Predstavitev"
+
+#: src/bin/ephoto_config.c:234
+msgid "Moving Slideshow"
+msgstr "Premična predstavitev"
+
+#: src/bin/ephoto_config.c:244
+msgid "Show Each Slide For"
+msgstr "Prikazuj vsako sliko"
+
+#: src/bin/ephoto_config.c:253
+msgid "seconds"
+msgstr "sek."
+
+#: src/bin/ephoto_config.c:265
+msgid "Slide Transition"
+msgstr "Prehod predstavitve"
+
+#: src/bin/ephoto_config.c:328 src/bin/ephoto_single_browser.c:1819
+#: src/bin/ephoto_single_browser.c:1858
+msgid "Save"
+msgstr "Shrani"
+
+#: src/bin/ephoto_config.c:339 src/bin/ephoto_config.c:478
+#: src/bin/ephoto_config.c:595 src/bin/ephoto_single_browser.c:1827
+msgid "Close"
+msgstr "Zapri"
+
+#: src/bin/ephoto_config.c:383
+msgid "Open Link In Browser"
+msgstr "Odpri bližnjico v brskalniku"
+
+#: src/bin/ephoto_config.c:391
+msgid "Copy Link"
+msgstr "Kopiraj povezavo"
+
+#: src/bin/ephoto_config.c:423
+msgid ""
+"General BindingsF1: Settings PanelF5: Start SlideshowF11: Toggle FullscreenCtrl"
+"+Shift+f: Toggle File SelectorThumbnail Browser "
+"BindingsCtrl++: Zoom InCtrl+-: Zoom "
+"OutCtrl+Tab: View ImageCtrl+c: Copy ImageCtrl"
+"+x: Cut ImageCtrl+v: Paste ImageCtrl+a: Select "
+"AllCtrl+f: Toggle SearchCtrl+Delete: Delete ImageF2: Rename ImageEscape: Clear SelectionSingle Browser BindingsCtrl+Shift+0: "
+"Zoom 1:1Ctrl++: Zoom InCtrl+-: Zoom OutCtrl"
+"+0: Zoom FitCtrl+Shift+l: Rotate Counter ClockwiseCtrl+l: Flip HorizontalCtrl+Shift+r: Rotate ClockwiseCtrl+r: Flip VerticalCtrl+Shift+s: Save Image AsCtrl+s: Save ImageCtrl+u: Reset ImageCtrl+y: "
+"RedoCtrl+Shift+z: RedoCtrl+z: UndoHome: "
+"Navigate FirstLeft Arrow: Navigate PreviousRight Arrow: Navigate NextEnd: Navigate LastCtrl+Delete: "
+"Delete ImageF2 Rename ImageEscape: Return to "
+"Thumbnail BrowserSlideshow BindingsSpace: 

[EGIT] [apps/empc] master 01/01: Adding slovenian translation

[maxerba]

maxerba pushed a commit to branch master.

http://git.enlightenment.org/apps/empc.git/commit/?id=f3e02cd99220a9cee346bbae79bb48b61f1197d8

commit f3e02cd99220a9cee346bbae79bb48b61f1197d8
Author: maxerba 
Date:   Wed Sep 21 21:43:36 2016 +0200

Adding slovenian translation
---
 po/LINGUAS |  2 +-
 po/sl.po   | 91 ++
 2 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/po/LINGUAS b/po/LINGUAS
index 3018168..02f9af5 100644
--- a/po/LINGUAS
+++ b/po/LINGUAS
@@ -1 +1 @@
-ca eo fr gl it lt pl pt ru sr tr ko
+ca eo fr gl it lt pl pt ru sl sr tr ko
diff --git a/po/sl.po b/po/sl.po
new file mode 100644
index 000..d9eff39
--- /dev/null
+++ b/po/sl.po
@@ -0,0 +1,91 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR Enlightenment development team
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR , YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: empc 0.99.0.639\n"
+"Report-Msgid-Bugs-To: enlightenment-devel@lists.sourceforge.net\n"
+"POT-Creation-Date: 2016-09-19 14:55+0200\n"
+"PO-Revision-Date: 2016-09-21 17:05+0200\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Poedit 1.8.9\n"
+"Last-Translator: Renato Rener \n"
+"Plural-Forms: nplurals=4; plural=(n%100==1 ? 0 : n%100==2 ? 1 : n%100==3 || 
n%100==4 ? 2 : 3);\n"
+"Language: sl_SI\n"
+
+#: src/enlightenment/e_mod_config.c:39
+msgid "eMPDule Configuration"
+msgstr "eMPDule nastavitve"
+
+#: src/enlightenment/e_mod_config.c:88
+msgid "Global Configuration"
+msgstr "Splošne nastavitve"
+
+#: src/enlightenment/e_mod_config.c:90
+msgid "Show OSD"
+msgstr "Pokaži zaslonski prikaz"
+
+#: src/enlightenment/e_mod_config.c:136
+msgid "Gadget Configuration"
+msgstr "Nastavitve pripomočkov"
+
+#: src/enlightenment/e_mod_config.c:137
+msgid "Hostname:"
+msgstr "Gostiteljsko ime:"
+
+#: src/enlightenment/e_mod_config.c:144
+msgid "Port:"
+msgstr "Vrata:"
+
+#: src/enlightenment/e_mod_config.c:149
+msgid "Show Gadget Popup"
+msgstr "Pokaži pojavnik gadžeta"
+
+#: src/enlightenment/e_mod_main.c:95
+msgid "Unknown"
+msgstr "Neznan"
+
+#: src/enlightenment/e_mod_main.c:98
+msgid "Stopped"
+msgstr "Zaustavljeno"
+
+#: src/enlightenment/e_mod_main.c:101
+msgid "Playing"
+msgstr "Predvajanje"
+
+#: src/enlightenment/e_mod_main.c:104
+msgid "Paused"
+msgstr "V premoru"
+
+#: src/enlightenment/e_mod_main.c:330
+msgid "Artist:"
+msgstr "Izvajalec:"
+
+#: src/enlightenment/e_mod_main.c:331
+msgid "Title:"
+msgstr "Naslov:"
+
+#: src/enlightenment/e_mod_main.c:332
+msgid "Album:"
+msgstr "Album:"
+
+#: src/enlightenment/e_mod_main.c:333
+msgid "Genre:"
+msgstr "Zvrst:"
+
+#: src/enlightenment/e_mod_main.c:402
+msgid "Settings"
+msgstr "Nastavitve"
+
+#: src/enlightenment/e_mod_main.c:651
+msgid "eMPDule"
+msgstr "eMPDule"
+
+#: src/enlightenment/e_mod_main.c:823
+msgid "MPDule"
+msgstr "MPDule"

-- 

[EGIT] [apps/ecrire] master 01/01: Adding slovenian translation

[maxerba]

maxerba pushed a commit to branch master.

http://git.enlightenment.org/apps/ecrire.git/commit/?id=2f09e4083dafa8f6e5a7186a6366de6325209060

commit 2f09e4083dafa8f6e5a7186a6366de6325209060
Author: maxerba 
Date:   Wed Sep 21 21:42:26 2016 +0200

Adding slovenian translation
---
 po/LINGUAS |   2 +-
 po/sl.po   | 143 +
 2 files changed, 144 insertions(+), 1 deletion(-)

diff --git a/po/LINGUAS b/po/LINGUAS
index d1250d6..3af1dbe 100644
--- a/po/LINGUAS
+++ b/po/LINGUAS
@@ -1 +1 @@
-ca eo es fr gl he hu it ko_KR lt pl pt sr tr zh_CN
+ca eo es fr gl he hu it ko_KR lt pl pt sl sr tr zh_CN
diff --git a/po/sl.po b/po/sl.po
new file mode 100644
index 000..b20adfe
--- /dev/null
+++ b/po/sl.po
@@ -0,0 +1,143 @@
+# Slovenian translation for enlightenment
+# Copyright (c) 2016 Rosetta Contributors and Canonical Ltd 2016
+# This file is distributed under the same license as the enlightenment package.
+# FIRST AUTHOR , 2016.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: enlightenment\n"
+"Report-Msgid-Bugs-To: FULL NAME \n"
+"POT-Creation-Date: 2015-06-02 20:00+0200\n"
+"PO-Revision-Date: 2016-09-21 16:51+0200\n"
+"Last-Translator: Renato Rener \n"
+"Language-Team: Slovenian \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Launchpad-Export-Date: 2016-09-16 20:28+\n"
+"X-Generator: Poedit 1.8.9\n"
+"Language: sl\n"
+
+#: src/bin/main.c:99
+#, c-format
+msgid "%s%s - %s"
+msgstr "%s%s - %s"
+
+#: src/bin/main.c:102
+#, c-format
+msgid "%sUntitled %d - %s"
+msgstr "%sNeimenovano %d - %s"
+
+#: src/bin/main.c:126
+#, c-format
+msgid "Ln %d, Col %d"
+msgstr "Vr %d, Stlp %d"
+
+#: src/bin/main.c:707
+msgid "New"
+msgstr "Nov"
+
+#: src/bin/main.c:708
+msgid "Open"
+msgstr "Odpri"
+
+#: src/bin/main.c:710 src/bin/ui/alerts.c:82
+msgid "Save"
+msgstr "Shrani"
+
+#: src/bin/main.c:711
+msgid "Save As"
+msgstr "Shrani kot"
+
+#: src/bin/main.c:716
+msgid "Undo"
+msgstr "Razveljavi"
+
+#: src/bin/main.c:718
+msgid "Redo"
+msgstr "Ponovno uveljavi"
+
+#: src/bin/main.c:721
+msgid "Cut"
+msgstr "Izreži"
+
+#: src/bin/main.c:723
+msgid "Copy"
+msgstr "Kopiraj"
+
+#: src/bin/main.c:725
+msgid "Paste"
+msgstr "Prilepi"
+
+#: src/bin/main.c:728 src/bin/ui/search_dialog.c:148
+msgid "Search"
+msgstr "Iskanje"
+
+#: src/bin/main.c:730 src/bin/ui/goto_dialog.c:60
+msgid "Jump to"
+msgstr "Skoči na"
+
+#: src/bin/main.c:733
+msgid "Settings"
+msgstr "Nastavitve"
+
+#: src/bin/ui/alerts.c:67
+msgid ""

[EGIT] [core/efl] master 01/01: Updating slovenian translation

[Massimo Maiurana]

maxerba pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=3c3c51f02970fe020897e8602396ac4808605e80

commit 3c3c51f02970fe020897e8602396ac4808605e80
Author: maxerba 
Date:   Wed Sep 21 21:40:50 2016 +0200

Updating slovenian translation
---
 po/sl.po | 227 +++
 1 file changed, 112 insertions(+), 115 deletions(-)

diff --git a/po/sl.po b/po/sl.po
index dc6ab3a..3b8841d 100644
--- a/po/sl.po
+++ b/po/sl.po
@@ -3,19 +3,19 @@
 # This file is put in the public domain.
 # r1to , 2011.
 #
-#: src/lib/elementary/elm_config.c:3766
 msgid ""
 msgstr ""
 "Project-Id-Version: Efl\n"
 "Report-Msgid-Bugs-To: enlightenment-devel@lists.sourceforge.net\n"
-"POT-Creation-Date: 2016-08-29 09:31+0900\n"
-"PO-Revision-Date: 2012-06-24 17:10+0900\n"
-"Last-Translator: Jerome Pinot \n"
+"POT-Creation-Date: 2016-08-11 13:52+0200\n"
+"PO-Revision-Date: 2016-09-21 17:00+0200\n"
+"Last-Translator: Renato Rener \n"
 "Language-Team: Enlightenment Team\n"
 "Language: sl\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Poedit 1.8.9\n"
 
 #: src/lib/ecore/ecore_getopt.c:89
 msgid "Version:"
@@ -26,9 +26,9 @@ msgid "Usage:"
 msgstr "Uporaba:"
 
 #: src/lib/ecore/ecore_getopt.c:105
-#, fuzzy, c-format
+#, c-format
 msgid "%s [options]"
-msgstr "%s·[možnosti]\n"
+msgstr "%s [možnosti]"
 
 #: src/lib/ecore/ecore_getopt.c:305
 msgid "Copyright:"
@@ -52,12 +52,11 @@ msgstr "Izbire:·"
 
 #: src/lib/ecore/ecore_getopt.c:644 src/lib/ecore/ecore_getopt.c:645
 msgid "No categories available."
-msgstr ""
+msgstr "Na voljo ni nobene kategorije"
 
 #: src/lib/ecore/ecore_getopt.c:649
-#, fuzzy
 msgid "Categories: "
-msgstr "Izbire:·"
+msgstr "Kategorije: "
 
 #: src/lib/ecore/ecore_getopt.c:771
 msgid "Options:\n"
@@ -65,22 +64,22 @@ msgstr "Možnosti:\n"
 
 #: src/lib/ecore/ecore_getopt.c:780
 msgid "Positional arguments:\n"
-msgstr ""
+msgstr "Argumenti nahajališča\n"
 
 #: src/lib/ecore/ecore_getopt.c:847
-#, fuzzy, c-format
+#, c-format
 msgid "ERROR: unknown category '%s'.\n"
-msgstr "NAPAKA:·Neznana možnost·--%s.\n"
+msgstr "NAPAKA: neznana kategorija '%s'.\n"
 
 #: src/lib/ecore/ecore_getopt.c:951
 #, c-format
 msgid "ERROR: unknown option --%s.\n"
-msgstr "NAPAKA:·Neznana možnost·--%s.\n"
+msgstr "NAPAKA:·Neznana možnost --%s.\n"
 
 #: src/lib/ecore/ecore_getopt.c:953
 #, c-format
 msgid "ERROR: unknown option -%c.\n"
-msgstr "NAPAKA:·neznana možnost·-%c.\n"
+msgstr "NAPAKA:·neznana možnost-%c.\n"
 
 #: src/lib/ecore/ecore_getopt.c:1016
 msgid "ERROR: "
@@ -157,14 +156,14 @@ msgid "ERROR: option -%c requires an argument!\n"
 msgstr "NAPAKA:·možnost·-%c zahteva argument!\n"
 
 #: src/lib/ecore/ecore_getopt.c:1878
-#, fuzzy, c-format
+#, c-format
 msgid "ERROR: missing required positional argument %s.\n"
-msgstr "NAPAKA:·možnost·-%c zahteva argument!\n"
+msgstr "NAPAKA: manjka zahtevani argument nahajališča %s.\n"
 
 #: src/lib/ecore/ecore_getopt.c:1910
 #, c-format
 msgid "ERROR: unsupported action type %d for positional argument %s\n"
-msgstr ""
+msgstr "NAPAKA: nepodprto dejanje vrste %d za argumente nahajališča %s\n"
 
 #: src/lib/ecore/ecore_getopt.c:2031 src/lib/ecore/ecore_getopt.c:2097
 msgid "ERROR: no parser provided.\n"
@@ -193,9 +192,8 @@ msgid " See -%c.\n"
 msgstr "·Glej·-%c.\n"
 
 #: src/lib/ecore/ecore_getopt.c:2137
-#, fuzzy
 msgid "ERROR: invalid positional arguments found."
-msgstr "NAPAKA::·najdene nepravilne možnosti"
+msgstr "NAPAKA: nepravilni argumenti nahajališča najdeni."
 
 #: src/lib/ecore/ecore_getopt.c:2172
 #, c-format
@@ -213,338 +211,337 @@ msgstr "Namizje"
 
 #: src/lib/efreet/efreet_base.c:131
 msgid "Downloads"
-msgstr ""
+msgstr "Prejemi"
 
 #: src/lib/efreet/efreet_base.c:140
 msgid "Templates"
-msgstr ""
+msgstr "Predloge"
 
 #: src/lib/efreet/efreet_base.c:149
 msgid "Public"
-msgstr ""
+msgstr "Javno"
 
 #: src/lib/efreet/efreet_base.c:158
 msgid "Documents"
-msgstr ""
+msgstr "Dokumenti"
 
 #: src/lib/efreet/efreet_base.c:166
 msgid "Music"
-msgstr ""
+msgstr "Glasba"
 
 #: src/lib/efreet/efreet_base.c:174
 msgid "Pictures"
-msgstr ""
+msgstr "Slike"
 
-#: src/lib/efreet/efreet_base.c:183
+#: src/lib/efreet/efreet_base.c:182
 msgid "Videos"
-msgstr ""
+msgstr "Videi"
 
-#: src/lib/elementary/elc_fileselector.c:1894
+#: src/lib/elementary/elc_fileselector.c:1873
 msgid "Up"
-msgstr ""
+msgstr "Gor"
 
-#: src/lib/elementary/elc_fileselector.c:1908
+#: src/lib/elementary/elc_fileselector.c:1887
 msgid "Home"
-msgstr ""
+msgstr "Dom"
 
-#: src/lib/elementary/elc_fileselector.c:1927
+#: src/lib/elementary/elc_fileselector.c:1906
 msgid "Search"
-msgstr ""
+msgstr "Poišči"
 
-#: src/lib/elementary/elc_fileselector.c:2128
+#: src/lib/elementary/elc_fileselector.c:2107
 #: src/lib/elementary/elm_entry.c:1700 src/lib/elementary/elm_entry.c:1725
 msgid 

[EGIT] [admin/devs] master 01/01: developers: add new pubkey for bdilly

[Bruno Dilly]

barbieri pushed a commit to branch master.

http://git.enlightenment.org/admin/devs.git/commit/?id=16f20461b092e4ba12e003b6852ef9af424a

commit 16f20461b092e4ba12e003b6852ef9af424a
Author: Bruno Dilly 
Date:   Wed Sep 21 15:28:01 2016 -0300

developers: add new pubkey for bdilly
---
 developers/bdilly/id_ed25519.pub | 1 +
 1 file changed, 1 insertion(+)

diff --git a/developers/bdilly/id_ed25519.pub b/developers/bdilly/id_ed25519.pub
new file mode 100644
index 000..2bc3fb9
--- /dev/null
+++ b/developers/bdilly/id_ed25519.pub
@@ -0,0 +1 @@
+ssh-ed25519 
C3NzaC1lZDI1NTE5IKx8HkXnjWd2VHxK85/lIAfcClYY8d0HNWdoCtGIBcbF 
bdilly@storm

-- 

[EGIT] [core/efl] master 01/01: emotion: convert Emotion_Object into Efl.Canvas.Video

[Yeshwanth Reddivari]

cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=7b90e1147442d6a8023422400bffd77e2815fe0b

commit 7b90e1147442d6a8023422400bffd77e2815fe0b
Author: Yeshwanth Reddivari 
Date:   Wed Sep 21 10:37:59 2016 -0700

emotion: convert Emotion_Object into Efl.Canvas.Video

Reviewers: singh.amitesh, raster, jpeg, cedric

Differential Revision: https://phab.enlightenment.org/D3994

Signed-off-by: Cedric BAIL 
---
 src/Makefile_Emotion.am|   2 +-
 src/lib/efl/interfaces/efl_player.eo   |   4 +-
 src/lib/elementary/efl_ui_video.c  |  20 +-
 src/lib/elementary/elc_player.c|  12 +-
 src/lib/emotion/Emotion_Eo.h   |   2 +-
 src/lib/emotion/Emotion_Legacy.h   |   3 +-
 .../{emotion_object.eo => efl_canvas_video.eo} |  50 ++-
 src/lib/emotion/emotion_smart.c| 344 -
 src/modules/ethumb/emotion/emotion.c   |  28 +-
 src/tests/emotion/emotion_test_main-eo.c   |  22 +-
 10 files changed, 261 insertions(+), 226 deletions(-)

diff --git a/src/Makefile_Emotion.am b/src/Makefile_Emotion.am
index 42966ce..8c31f41 100644
--- a/src/Makefile_Emotion.am
+++ b/src/Makefile_Emotion.am
@@ -1,7 +1,7 @@
 ### Library
 
 emotion_eolian_files = \
-   lib/emotion/emotion_object.eo
+   lib/emotion/efl_canvas_video.eo
 
 emotion_eolian_c = $(emotion_eolian_files:%.eo=%.eo.c)
 emotion_eolian_h = $(emotion_eolian_files:%.eo=%.eo.h) \
diff --git a/src/lib/efl/interfaces/efl_player.eo 
b/src/lib/efl/interfaces/efl_player.eo
index 41b1395..b95780a 100644
--- a/src/lib/efl/interfaces/efl_player.eo
+++ b/src/lib/efl/interfaces/efl_player.eo
@@ -71,7 +71,7 @@ interface Efl.Player {
   speed: double; [[The play speed in the [0, infinity) range.]]
  }
 }
-@property audio_volume {
+@property volume {
  [[Control the audio volume.
 
Controls the audio volume of the stream being played. This has
@@ -88,7 +88,7 @@ interface Efl.Player {
   volume: double; [[The volume level]]
  }
 }
-@property audio_mute {
+@property mute {
  [[This property controls the audio mute state.]]
  set {
  }
diff --git a/src/lib/elementary/efl_ui_video.c 
b/src/lib/elementary/efl_ui_video.c
index 8c107a3..5808353 100644
--- a/src/lib/elementary/efl_ui_video.c
+++ b/src/lib/elementary/efl_ui_video.c
@@ -50,12 +50,12 @@ static const Elm_Action key_actions[] = {
 };
 
 EFL_CALLBACKS_ARRAY_DEFINE(_video_cb,
-   { EMOTION_OBJECT_EVENT_OPEN_DONE, _on_open_done },
-   { EMOTION_OBJECT_EVENT_PLAYBACK_STARTED, _on_playback_started },
-   { EMOTION_OBJECT_EVENT_PLAYBACK_FINISHED, _on_playback_finished },
-   { EMOTION_OBJECT_EVENT_FRAME_RESIZE, _on_aspect_ratio_updated },
-   { EMOTION_OBJECT_EVENT_TITLE_CHANGE, _on_title_changed },
-   { EMOTION_OBJECT_EVENT_AUDIO_LEVEL_CHANGE, _on_audio_level_changed }
+   { EFL_CANVAS_VIDEO_EVENT_OPEN_DONE, _on_open_done },
+   { EFL_CANVAS_VIDEO_EVENT_PLAYBACK_START, _on_playback_started },
+   { EFL_CANVAS_VIDEO_EVENT_PLAYBACK_STOP, _on_playback_finished },
+   { EFL_CANVAS_VIDEO_EVENT_FRAME_RESIZE, _on_aspect_ratio_updated },
+   { EFL_CANVAS_VIDEO_EVENT_TITLE_CHANGE, _on_title_changed },
+   { EFL_CANVAS_VIDEO_EVENT_VOLUME_CHANGE, _on_audio_level_changed }
 );
 
 static Eina_Bool
@@ -426,25 +426,25 @@ elm_video_file_get(Eo *obj, const char **filename)
 EAPI void
 elm_video_audio_level_set(Evas_Object *obj, double volume)
 {
-   efl_player_audio_volume_set(obj, volume);
+   efl_player_volume_set(obj, volume);
 }
 
 EAPI double
 elm_video_audio_level_get(const Evas_Object *obj)
 {
-   return efl_player_audio_volume_get(obj);
+   return efl_player_volume_get(obj);
 }
 
 EAPI void
 elm_video_audio_mute_set(Evas_Object *obj, Eina_Bool mute)
 {
-   efl_player_audio_mute_set(obj, mute);
+   efl_player_mute_set(obj, mute);
 }
 
 EAPI Eina_Bool
 elm_video_audio_mute_get(const Evas_Object *obj)
 {
-   return efl_player_audio_mute_get(obj);
+   return efl_player_mute_get(obj);
 }
 
 EAPI double
diff --git a/src/lib/elementary/elc_player.c b/src/lib/elementary/elc_player.c
index 86c4165..f59be6f 100644
--- a/src/lib/elementary/elc_player.c
+++ b/src/lib/elementary/elc_player.c
@@ -78,12 +78,12 @@ static const Elm_Action key_actions[] = {
 };
 
 EFL_CALLBACKS_ARRAY_DEFINE(_emotion_cb,
-   { EMOTION_OBJECT_EVENT_FRAME_DECODE, _update_frame },
-   { EMOTION_OBJECT_EVENT_FRAME_RESIZE, _update_slider },
-   { EMOTION_OBJECT_EVENT_LENGTH_CHANGE, _update_slider },
-   { EMOTION_OBJECT_EVENT_POSITION_UPDATE, _update_frame },
-   { EMOTION_OBJECT_EVENT_PLAYBACK_STARTED, _play_started },
-   { EMOTION_OBJECT_EVENT_PLAYBACK_FINISHED, _play_finished }
+   { EFL_CANVAS_VIDEO_EVENT_FRAME_DECODE, _update_frame },
+ 

Re: [E-devel] EFL interface, what's left to be done

[Cedric BAIL]

Hi JP,

On Tue, Sep 20, 2016 at 11:52 PM, Jean-Philippe André  wrote:
> On 20 September 2016 at 06:05, Cedric BAIL  wrote:
>> So this email is going over what is left to be done to call EFL
>> interface done. Most of this require still discussion also. Here it
>> goes :
>>
>> - Merge Eo, Efl and Ecore
>> - Make efl_uri_set/efl_file_set asynchronous
>> - Convert Ecore_Exe to the new efl_io API
>> - Fixup efl/interface/*.eo to all be in the correct namespace
>> - Disable installation of evas/canvas/evas*.eo
>> - Convert edje to become efl_canvas_layout
>> - Update Edje with the new Text API
>> - Convert elm_layout to become efl_ui_layout
>> - Convert elm_widget to be an efl_ui_object of some sort
>> - Update all efl data model to use efl_future/efl_promise
>> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
>> ideas)
>> - There is still a large amount of .eo in elementary that are in elm
>> namespace. This shouldn't be installed nor appear anywhere in the
>> hierarchy.
>> - Finish porting some of the widget to Efl.Ui namespace (photocam,
>> index, entry, button, calendar, clock, menu, ...). This needs to be
>> clarified with some pending patch in phab.
>>
>> This are quite a large todo list to be done with, hopefully it will...
>>
>
> - evas smart objects
> Evas smart objects are a stable legacy API but their equivalent in EO is
> horrible. Efl.Canvas.Group is not an acceptable replacement in its current
> form. All the methods this class defines are poorly defined overrides over
> the basic object functions (show, hide, etc...). I've started some work in
> this direction but it's tedious and risky. The alternative is to have no
> API for custom smart objects.
>
> - elm_widget
> elm widget was and still is an unstable / private API. I don't think
> cleaning up this API is in the scope of our interfaces work, right now.

I kind of forgot about smart object and not really. Well, I was
wondering if we could make elm_widget the exposed way of doing smart
object with efl interface. I guess it would be indeed to big of a
scope. I am fine with focusing on a simpler evas level smart object.
The problem is that elm_widget is in the hierarchy of every elementary
widget. So at least some binding may expose it in some way. We need a
way to hide/reduce the visibility of that API at least.

> - text part API
> Textblock now has a new shiny eo api but edje_object and elm_layout still
> define _part_text_ APIs. This needs to be transformed to Efl.Part.

Yup, that was my point regarding updating edje and elm entry to use
the new text API. A huge work and I have no idea of its current
status.

> - efl.ui.window + elm_conformant
> Ideally window should have merged in the features of conformant so we avoid
> this extra awkward widget. Window was supposed to handle what conformant
> does. The reality is that no work towards that goal has been done yet.

Oh, I missed that bit. Hum, that's problematic indeed. Need to be done.

Thanks,
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [tools/eflete] master 01/01: Syntox color: delete unreachable statement.

[Mykyta Biliavskyi]

rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=03c23448f30c617ddfb6da241b7aa036c7612a5e

commit 03c23448f30c617ddfb6da241b7aa036c7612a5e
Author: Mykyta Biliavskyi 
Date:   Wed Sep 21 17:26:13 2016 +0300

Syntox color: delete unreachable statement.

@svace WGID 20029 and WGID 20052
@fix
---
 src/bin/external/syntax_color.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/bin/external/syntax_color.c b/src/bin/external/syntax_color.c
index 77fca78..1cbf860 100644
--- a/src/bin/external/syntax_color.c
+++ b/src/bin/external/syntax_color.c
@@ -279,8 +279,6 @@ markup_skip(Eina_Strbuf *strbuf, const char **src, int 
length, char **cur,
 *prev = *cur;
 return -1;
  }
-
-   return 1;
 }
 
 static int
@@ -347,8 +345,6 @@ comment_apply(Eina_Strbuf *strbuf, const char **src, int 
length, char **cur,
 *prev = *cur;
 return 1;
  }
-
-   return -1;
 }
 
 static int

-- 

[EGIT] [core/efl] master 02/02: emile: fix typos.

[Cedric BAIL]

cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=cbfcfdf3e90906e31f8defc65d17747c28e19f57

commit cbfcfdf3e90906e31f8defc65d17747c28e19f57
Author: Cedric BAIL 
Date:   Wed Sep 21 10:34:05 2016 -0700

emile: fix typos.
---
 src/lib/emile/emile_cipher_gnutls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/emile/emile_cipher_gnutls.c 
b/src/lib/emile/emile_cipher_gnutls.c
index cb6492a..966859b 100644
--- a/src/lib/emile/emile_cipher_gnutls.c
+++ b/src/lib/emile/emile_cipher_gnutls.c
@@ -169,7 +169,7 @@ EAPI Eina_Bool
 emile_binbuf_sha1(const Eina_Binbuf * data, unsigned char digest[20])
 {
Eina_Slice slice = eina_binbuf_slice_get(data);
-   return emile_sha1(data.mem, data.len, digest);
+   return emile_sha1(slice.mem, slice.len, digest);
 }
 
 EAPI Eina_Binbuf *

-- 

[EGIT] [core/efl] master 01/02: eet: fix gnutls support with newer version.

[Cedric BAIL]

cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=6f42992b4f1110f44d2db57cd6fe42559cfffdc2

commit 6f42992b4f1110f44d2db57cd6fe42559cfffdc2
Author: Cedric BAIL 
Date:   Wed Sep 21 10:33:44 2016 -0700

eet: fix gnutls support with newer version.
---
 src/lib/eet/eet_cipher.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/lib/eet/eet_cipher.c b/src/lib/eet/eet_cipher.c
index a34fdff..cf9ef71 100644
--- a/src/lib/eet/eet_cipher.c
+++ b/src/lib/eet/eet_cipher.c
@@ -679,7 +679,6 @@ eet_identity_check(const void   *data_base,
gnutls_datum_t datum;
gnutls_datum_t signature;
gnutls_pubkey_t pubkey;
-   gnutls_digest_algorithm_t hash_algo;
unsigned char *hash;
gcry_md_hd_t md;
int err;
@@ -717,10 +716,10 @@ eet_identity_check(const void   *data_base,
if (gnutls_pubkey_import_x509(pubkey, cert, 0) < 0)
  goto on_error;
 
-   if (gnutls_pubkey_get_verify_algorithm(pubkey, , _algo) < 0)
- goto on_error;
-
-   if (gnutls_pubkey_verify_hash(pubkey, 0, , ) < 0)
+   if (gnutls_pubkey_verify_hash2(pubkey,
+  
gnutls_x509_crt_get_signature_algorithm(cert),
+  0,
+  , ) < 0)
  goto on_error;
 
if (sha1)

-- 

[EGIT] [core/enlightenment] master 01/01: Revert "protect against non-nul terminated string from mmap in filepreview"

[Cedric BAIL]

cedric pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=ff0b513daa52a5d8db417e7b603f1e268d954dbe

commit ff0b513daa52a5d8db417e7b603f1e268d954dbe
Author: Cedric BAIL 
Date:   Wed Sep 21 09:34:31 2016 -0700

Revert "protect against non-nul terminated string from mmap in filepreview"

This reverts commit 5861d9bef949c64cbc7ddad31b4ac2cc70bb6440.

T4543 was already fixed by ae23533b0d5e218d8943427a6ca3bf49b3797b93.
---
 src/bin/e_widget_filepreview.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/bin/e_widget_filepreview.c b/src/bin/e_widget_filepreview.c
index 1f91073..2602895 100644
--- a/src/bin/e_widget_filepreview.c
+++ b/src/bin/e_widget_filepreview.c
@@ -931,13 +931,8 @@ _e_wid_fprev_preview_txt_map_success(void *data, Eio_File 
*handler EINA_UNUSED,
char *msg;
Evas_Coord mw, mh;
 
-   msg = malloc(length + 1);
-   if (!msg) return;
-   strncpy(msg, map, length);
-   msg[length] = 0;
buf = eina_strbuf_new();
-   eina_strbuf_append_length(buf, msg, length);
-   free(msg);
+   eina_strbuf_append_length(buf, map, length);
msg = evas_textblock_text_utf8_to_markup(NULL, eina_strbuf_string_get(buf));
eina_strbuf_reset(buf);
 

-- 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: protect against non-nul terminated string from mmap in filepreview

[Cedric BAIL]

On Sep 21, 2016 4:18 AM, "Carsten Haitzler"  wrote:
>
> raster pushed a commit to branch master.
>
>
http://git.enlightenment.org/core/enlightenment.git/commit/?id=5861d9bef949c64cbc7ddad31b4ac2cc70bb6440
>
> commit 5861d9bef949c64cbc7ddad31b4ac2cc70bb6440
> Author: Carsten Haitzler (Rasterman) 
> Date:   Wed Sep 21 20:18:01 2016 +0900
>
> protect against non-nul terminated string from mmap in filepreview
>
> this should address 2nd gdb bt and fix T4543

No ! This patch is unnecessary or more exactly too late. Previous code was
using the _n variant of append which call strlen. The current code only
rely on the given length. Will revert.

> @fix
> ---
>  src/bin/e_widget_filepreview.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/bin/e_widget_filepreview.c
b/src/bin/e_widget_filepreview.c
> index 2602895..1f91073 100644
> --- a/src/bin/e_widget_filepreview.c
> +++ b/src/bin/e_widget_filepreview.c
> @@ -931,8 +931,13 @@ _e_wid_fprev_preview_txt_map_success(void *data,
Eio_File *handler EINA_UNUSED,
> char *msg;
> Evas_Coord mw, mh;
>
> +   msg = malloc(length + 1);
> +   if (!msg) return;
> +   strncpy(msg, map, length);
> +   msg[length] = 0;
> buf = eina_strbuf_new();
> -   eina_strbuf_append_length(buf, map, length);
> +   eina_strbuf_append_length(buf, msg, length);
> +   free(msg);
> msg = evas_textblock_text_utf8_to_markup(NULL,
eina_strbuf_string_get(buf));
> eina_strbuf_reset(buf);
>
>
> --
>
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/enlightenment] master 01/01: Fix xwayland binary location detection

[Derek Foreman]

derekf pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=47cdbdb5af1d6029538beeab22c2b632866a574c

commit 47cdbdb5af1d6029538beeab22c2b632866a574c
Author: Derek Foreman 
Date:   Mon Sep 19 15:24:58 2016 -0500

Fix xwayland binary location detection

We were trying to find it with pkg-config and failing, try
AC_PATH_PROG instead
---
 configure.ac | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index e35493c..0e5f3be 100644
--- a/configure.ac
+++ b/configure.ac
@@ -788,12 +788,16 @@ define([CHECK_MODULE_XWAYLAND],
 [
   if test "x${have_wayland}" = "xyes"; then
 AC_E_CHECK_PKG(XWAYLAND, [ ecore-x >= ${efl_version} ecore-audio >= 
${efl_version}  ], [HAVE_XWAYLAND_DEPS=true], [HAVE_XWAYLAND_DEPS=false])
-EFL_WITH_BIN([Xwayland], [Xwayland], [Xwayland])
-if test -z "x${Xwayland}" ; then
-  HAVE_XWAYLAND_DEPS=false
+AC_ARG_WITH(Xwayland, AS_HELP_STRING([--with-Xwayland=PATH], [Path to 
Xwayland]), [Xwayland_with="$withval"], [Xwayland_with="yes"])
+if test "x${Xwayland_with}" != "xyes"; then
+  xwayland=$Xwayland_with
+  AC_SUBST(xwayland)
+else
+  AC_PATH_PROG(xwayland, Xwayland, "no")
+fi
+if test "x${xwayland}" == "xno"; then
+  AC_MSG_ERROR([Xwayland enabled but not found.])
 fi
-  else
-HAVE_XWAYLAND_DEPS=false
   fi
 ])
 AM_CONDITIONAL([HAVE_XWAYLAND], [test "x${HAVE_XWAYLAND}" != "xno"])

-- 

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
> [...]
>>> promise/future should be first-class citizen... as well as iterator
>>> and the likes. There is a start already, but refinement is really
>>> needed, like returning an iterator should handle warn_unused, free,
>>> own... Promise should have its own callback signature, simplified for
>>> the user.
>>>
>>
>> They can, be, but they will just be provided by Eo. There's no need for
>> any special treatment in Eo.
>>
>> Promise signature: you don't need to do it in Eo. I mean, you can add a
>> special type in Eolian, but Eo itself need not be aware. Also, I disagree.
>
> Do you mean still use Eo's events to dispatch promises?

Not necessarily, just use the same signature because it's a good one, 
it's extendable, it applies here too, and it's easier for bindings this way.

>
> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
> now hints of benefits. Asking Cedric leads me to an awful answer...
> :-/
>
> The promise thing should only be a thin layer that forces a clear
> pattern: wait for data, deliver data or call failure. I don't get why
> in the other thread people were talking about references in promises,
> inheritance, etc.
>

Not sure about inheritance, but you need references for lifecycle. It's 
even better when you have automatic lifecycle control, so when an object 
dies, the associated promise dies too.

>
>>> AND if possible, make eolian or a new tool to handle connections for
>>> us, if it was easy to declare objects with composition of
>>> events/promises, it would save us lots of typing and errors.
>>>
>>>
>>
>> I'm not sure what you meant here.
>
> the process of creating and object, setting its properties and
> connecting events is painful in C. We need to replicate the whole
> "_${METHOD}(efl_added, ${VALUE})"... for events it's even
> worse.
>
> While the API is what it should be, it's PITA to use. If we could
> extend the generator to do those for us, we'd have to implement only
> high level functions. Like it does for C++ or Lua bindings, do to C
> "user code" (could also do C++/Lua user code as well). Example:
>
> myapp.eou:  # eou = eo user
>
> objects {
> xpto { /* creates an object called "xpto" */
>children {
>   window { /* window is part of xpto, it will be created using
> given type and properties */
>  type: Efl.Ui.Win;
>  constructor {
> type: Efl.Ui.Win.Type.basic;
> title: "hello world";
>  }
>  events { /* these will be connected for you, callback
> handlers are expanded based on event payload */
> resized @proxy; /* proxy = will forward this event as
> "xpto" using the same name */
> delete,request; /* user must implement the callback
> with handler */
>  }
>   }
>   box {
>  type: Efl.Ui.Box;
>   }
>   label1 {
>  type: Efl.Ui.Label;
>   }
>   label2 {
>  type: Efl.Ui.Label;
>   }
>   entry {
>  type: Efl.Ui.Entry;
>   }
>   }
>
>connections {
>   entry: changed -> label2: text.set; /* somehow like Qt's
> signal connection */
>}
>
>composition { /* basic method calls using other objects and constants 
> */
>box.pack_align(0.5, 0.5);
>
>label1.hint_align.set(0.0, 0.0);
>box.pack(label1);
>
>label2.hint_align.set(1.0, 1.0);
>box.pack(label2);
>box.pack(entry);
>  }
> }
> }
>
>
> Then in my code I'd just:
>
> #include "myapp.eou.h"
>
> static void _xpto_window_delete_request(Eo *xpto, Eo *window) /*
> nothing else as there is no payload in that event */
> {
> printf("window was closed\n");
> }
>
> static void _xpto_resized(void *data, const Efl_Event *event) // or we
> create an xpto_event_resized_add() which unpacks and makes it easier
> to use
> {
> }
>
> int main() {
>  // ...
>
>  Eo *xpto = xpto_new();
>  efl_event_callback_add(xpto, XPTO_EVENT_RESIZED, _xpto_resized, NULL);
>
>   // ...
> }
>
> #include "myapp.eou.c"
>


If I understand you correctly, you want a UI description language. Yes, 
we have that in the words under the "erigo" project. Erigo is the gui 
builder but it also implement a UI descrption language and should 
include cli tools that do just that. We already speced the language, 
though unfortunately the author is currently unavailable, so work stopped.

--
Tom.

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efl.Net and libproxy

[Simon Lees]

On 09/22/2016 12:02 AM, Gustavo Sverzut Barbieri wrote:
> On Wed, Sep 21, 2016 at 9:27 AM, Simon Lees  wrote:
>>
>>
>> On 09/21/2016 12:33 AM, Gustavo Sverzut Barbieri wrote:
>>> On Tue, Sep 20, 2016 at 11:43 AM, Simon Lees  wrote:


 On 09/20/2016 02:24 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
>> wrote:
>>> On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
>>>  said:
>>>
 Hi all,

 Today I did commit support for libproxy in ecore_con's new API,
 Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
 (implicit from HTTP).
>>>
>>> ummm i just am looking now (i have a lot of catching up to do). can you 
>>> undo
>>> the changes to configure.ac and make this a dlopen/dlsym approach? well 
>>> use
>>> eina_module. look a the old curl eina_module approach. look at what i 
>>> did in
>>> ecore_audio too. in fact i need to look over all the efl net code, but 
>>> you
>>> want to use emile for ssl stuff and eina_module for curl too there too 
>>> (i
>>> haven't looked yet). there are very good reasons to do all of this.
>>
>> I've checked what you did for curl, since I use that and need more 
>> symbols.
>>
>> my question and concern are just:
>>  - not being able to compile without libproxy. If we always detect,
>> should we remove --enable-libproxy from configure.ac?
>
> yes. it moves to runtime not compile-time. several reasons:
>
> 1. makes compiling simpler. people dont have to find dependencies and 
> those
> -dev/devel pkgs too. if they add libproxy later after building efl 
> magically
> the feature works without a rebuild.

 No no no, just Never that is about the most evil thing you can do if
 there is no configure check distro's won't know that it should be pulled
 in as a dependency and you will end up with different behavior on
 different machines because one has a completely unrelated package
 installed which also installed the dependency.

 Keep the ./configure check, add a --disable-libproxy flag for those that
 don't want to go find it and sure after that dlopen it or whatever. But
 the #1 priority should be making sure that distro packagers don't screw
 it up because after all in a ideal world thats how most people should
 get efl, sure make it easy enough for anyone to compile but don't make
 it easier for distros to shoot there users in the foot by not realising
 theres a extra dependency that probably should be pulled in. Unless of
 course libproxy is not useful on a normal Linux distro and will only
 ever be used in embedded contexts.
>>>
>>> Simon, although I do understand your PoV -- packaging -- Raster is
>>> right and is concerned about runtime impact on non-users.
>>>
>>> If you link to a library, particularly one that has a huge dep graph
>>> like libproxy, you end pulling too much and impacting everyone... even
>>> if that's not used.
>>>
>>
>> So how big in filesize are we talking about? if the distro ships
>> libproxy and isn't slackware it will take care of the dependency graph
>> on its own, if the distro doesn't have it the packager / user can then
>> just pass the --disable flag when building. "Large dependency chain"
>> shouldn't really be an argument distro's handle this fine.
> 
> it's not about disk footprint, rather memory footprint.
> 
> say you use terminology without the URL preview... then why should you
> be linking with libproxy, which in turn will link with glib, mozjs...
> 
> once, if you click an URL, it will dlopen() libproxy and pull those.
> 

Ahh i'm not talking about not dlopening, I just want there to be a
configure check for the library as well as dlopening so that people are
atleast aware they should install it on there system.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efl.Net and libproxy

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 9:27 AM, Simon Lees  wrote:
>
>
> On 09/21/2016 12:33 AM, Gustavo Sverzut Barbieri wrote:
>> On Tue, Sep 20, 2016 at 11:43 AM, Simon Lees  wrote:
>>>
>>>
>>> On 09/20/2016 02:24 PM, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
  said:

> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
> wrote:
>> On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
>>  said:
>>
>>> Hi all,
>>>
>>> Today I did commit support for libproxy in ecore_con's new API,
>>> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
>>> (implicit from HTTP).
>>
>> ummm i just am looking now (i have a lot of catching up to do). can you 
>> undo
>> the changes to configure.ac and make this a dlopen/dlsym approach? well 
>> use
>> eina_module. look a the old curl eina_module approach. look at what i 
>> did in
>> ecore_audio too. in fact i need to look over all the efl net code, but 
>> you
>> want to use emile for ssl stuff and eina_module for curl too there too (i
>> haven't looked yet). there are very good reasons to do all of this.
>
> I've checked what you did for curl, since I use that and need more 
> symbols.
>
> my question and concern are just:
>  - not being able to compile without libproxy. If we always detect,
> should we remove --enable-libproxy from configure.ac?

 yes. it moves to runtime not compile-time. several reasons:

 1. makes compiling simpler. people dont have to find dependencies and those
 -dev/devel pkgs too. if they add libproxy later after building efl 
 magically
 the feature works without a rebuild.
>>>
>>> No no no, just Never that is about the most evil thing you can do if
>>> there is no configure check distro's won't know that it should be pulled
>>> in as a dependency and you will end up with different behavior on
>>> different machines because one has a completely unrelated package
>>> installed which also installed the dependency.
>>>
>>> Keep the ./configure check, add a --disable-libproxy flag for those that
>>> don't want to go find it and sure after that dlopen it or whatever. But
>>> the #1 priority should be making sure that distro packagers don't screw
>>> it up because after all in a ideal world thats how most people should
>>> get efl, sure make it easy enough for anyone to compile but don't make
>>> it easier for distros to shoot there users in the foot by not realising
>>> theres a extra dependency that probably should be pulled in. Unless of
>>> course libproxy is not useful on a normal Linux distro and will only
>>> ever be used in embedded contexts.
>>
>> Simon, although I do understand your PoV -- packaging -- Raster is
>> right and is concerned about runtime impact on non-users.
>>
>> If you link to a library, particularly one that has a huge dep graph
>> like libproxy, you end pulling too much and impacting everyone... even
>> if that's not used.
>>
>
> So how big in filesize are we talking about? if the distro ships
> libproxy and isn't slackware it will take care of the dependency graph
> on its own, if the distro doesn't have it the packager / user can then
> just pass the --disable flag when building. "Large dependency chain"
> shouldn't really be an argument distro's handle this fine.

it's not about disk footprint, rather memory footprint.

say you use terminology without the URL preview... then why should you
be linking with libproxy, which in turn will link with glib, mozjs...

once, if you click an URL, it will dlopen() libproxy and pull those.

-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efl.Net and libproxy

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 9:08 AM, Carsten Haitzler  wrote:
> On Tue, 20 Sep 2016 19:12:57 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> damn raster... I had to do so I could check.
>>
>> dlopen -> in git.
>>
>> server and libproxy.so wrapper, attached with the basics, I'm not
>> doing all the cumbersome details to get a single process running and
>> spawn it from libproxy.so wrapper without a race condition.
>
> there is no race.
>
> connect. if connect fail, spawn, set timer to connect every 0.1 sec until
> successful.
>
> there is no race. first daemon spawned that binds to the socket wins. every
> other one will fail and exit. there is no race to deal with as the bind does
> the job for the daemon - first one in wins and the rest fail.

there is a problem with stale sockets. If daemon dies and leaves the
socket file, then next daemons will try to bind and fail... then
nobody wins. If we first unlink(), then there is a race.

Or should we use an abstract socket?



>> I'd simplify all of that by using dbus with acquiring a name in the
>> session bus and let that entity control it. Also would let the dbus
>> daemon set isolation, like not inheriting current processes limits,
>> namespaces and all.
>
> no it isn't any easier with dbus. see above. this is what efreetd does not. 
> its
> REALLyYsimple and race-free.

still doesn't address inheriting caps and other access controls...

say constrained process A spawned the daemon. Then unconstrained
process B will get the constraints.

more concrete description is: for some reason "A" was started without
network access. The daemon inherits that and thus libproxy won't work.
That's okay, expected.

However "B" has network access and is started afterwards, it will
check and the daemon is there. It will use the daemon with libproxy
that doesn't work due lack of network access. This is not expected.

I know not all systems employ fine grained capabilities and
smack/selinux, but some do and we need to be careful.

What I can do to solve this is to allow the server to be started from
socket activation like systemd (also in --user variant). In that case,
if the user cares about isolation, he uses the
efl-proxy-resolver.socket and efl-proxy-resolver.service to start
those on demand. The client will try to connect and it will work, thus
it won't spawn any daemon on its own. Systemd will spawn the service
with proper caps.

If systemd is not used, then the client will fail to connect, will
fork-exec the daemon and it will create and bind the socket on its
own, inheriting parent's caps. A possible workaround for this is to
die after some idle timeout, then it would "auto-fix" if problems like
that happens.

looks good?



>> however as you dislike that, be my guest :-D
>>
>>  gcc -o efl-proxy-resolver libproxy-efl-server.c `pkg-config --cflags
>> --libs ecore eina efl eo libproxy-1.0`
>>  gcc -shared -o libproxy-efl.so libproxy-efl.c `pkg-config --cflags
>> eina` -lpthread
>
> why did you do both a client exe and a server? just need the server... the
> client copnnect/talk is in efl.net :) if you use efl.net like ecore_con it'd 
> do
> the XDG_RUNTIME_DIR for you for user local sockets (unless they are full 
> path).
> yuou just should have re-use efl.net inside there.

client is not an exe, it's a libproxy.so drop-in replacement so you
can LD_PRELOAD, like from E... after all you want all your processes
to use the same proxy configuration and benefits, right? VLC, glib,
qt...

-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [elementary] the number of action buttons in popup

[임제헌]

Hi all,

I have a question about popup widget.

Action area can have up to 3 buttons.
In the code, ELM_POPUP_ACTION_BUTTON_MAX value is defined as 3.

What is the reason of this restriction?

Is it possible to increase the available number of buttons just by
modifying ELM_POPUP_ACTION_BUTTON_MAX?

Thanks,

Jehun Lim
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
[...]
>> promise/future should be first-class citizen... as well as iterator
>> and the likes. There is a start already, but refinement is really
>> needed, like returning an iterator should handle warn_unused, free,
>> own... Promise should have its own callback signature, simplified for
>> the user.
>>
>
> They can, be, but they will just be provided by Eo. There's no need for
> any special treatment in Eo.
>
> Promise signature: you don't need to do it in Eo. I mean, you can add a
> special type in Eolian, but Eo itself need not be aware. Also, I disagree.

Do you mean still use Eo's events to dispatch promises?

I don't get why Efl.Promise is an Eo at all. Looking at the code shows
now hints of benefits. Asking Cedric leads me to an awful answer...
:-/

The promise thing should only be a thin layer that forces a clear
pattern: wait for data, deliver data or call failure. I don't get why
in the other thread people were talking about references in promises,
inheritance, etc.


>> AND if possible, make eolian or a new tool to handle connections for
>> us, if it was easy to declare objects with composition of
>> events/promises, it would save us lots of typing and errors.
>>
>>
>
> I'm not sure what you meant here.

the process of creating and object, setting its properties and
connecting events is painful in C. We need to replicate the whole
"_${METHOD}(efl_added, ${VALUE})"... for events it's even
worse.

While the API is what it should be, it's PITA to use. If we could
extend the generator to do those for us, we'd have to implement only
high level functions. Like it does for C++ or Lua bindings, do to C
"user code" (could also do C++/Lua user code as well). Example:

myapp.eou:  # eou = eo user

objects {
xpto { /* creates an object called "xpto" */
   children {
  window { /* window is part of xpto, it will be created using
given type and properties */
 type: Efl.Ui.Win;
 constructor {
type: Efl.Ui.Win.Type.basic;
title: "hello world";
 }
 events { /* these will be connected for you, callback
handlers are expanded based on event payload */
resized @proxy; /* proxy = will forward this event as
"xpto" using the same name */
delete,request; /* user must implement the callback
with handler */
 }
  }
  box {
 type: Efl.Ui.Box;
  }
  label1 {
 type: Efl.Ui.Label;
  }
  label2 {
 type: Efl.Ui.Label;
  }
  entry {
 type: Efl.Ui.Entry;
  }
  }

   connections {
  entry: changed -> label2: text.set; /* somehow like Qt's
signal connection */
   }

   composition { /* basic method calls using other objects and constants */
   box.pack_align(0.5, 0.5);

   label1.hint_align.set(0.0, 0.0);
   box.pack(label1);

   label2.hint_align.set(1.0, 1.0);
   box.pack(label2);
   box.pack(entry);
 }
}
}


Then in my code I'd just:

#include "myapp.eou.h"

static void _xpto_window_delete_request(Eo *xpto, Eo *window) /*
nothing else as there is no payload in that event */
{
printf("window was closed\n");
}

static void _xpto_resized(void *data, const Efl_Event *event) // or we
create an xpto_event_resized_add() which unpacks and makes it easier
to use
{
}

int main() {
 // ...

 Eo *xpto = xpto_new();
 efl_event_callback_add(xpto, XPTO_EVENT_RESIZED, _xpto_resized, NULL);

  // ...
}

#include "myapp.eou.c"



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 3:39 AM, Jean-Philippe André  wrote:
> Hi Gustavo,
>
> On 21 September 2016 at 07:11, Carsten Haitzler 
> wrote:
>
>> On Tue, 20 Sep 2016 12:17:50 -0300 Gustavo Sverzut Barbieri
>>  said:
>>
>> > On Tue, Sep 20, 2016 at 11:18 AM, Carsten Haitzler > >
>> > wrote:
>> > > On Tue, 20 Sep 2016 08:16:21 -0300 Gustavo Sverzut Barbieri
>> > >  said:
>> > >
>> > >> On Tue, Sep 20, 2016 at 5:51 AM, Jean-Philippe André <
>> j...@videolan.org>
>> > >> wrote:
>> > >> > Hi Gustavo,
>> > >> >
>> > >> > On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri
>> > >> >  wrote:
>> > >> >
>> > >> >> HEADS UP -- BINDINGS:
>> > >> >>
>> > >> >> If you wish to expose the new "cancellable" property, or cope with
>> > >> >> naughty users or 3rd party deps that may call
>> > >> >> pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register
>> your
>> > >> >> cleanup functions with:
>> > >> >>
>> > >> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
>> > >> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
>> > >> >>call_user();
>> > >> >>EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean
>> exit
>> > >> >>
>> > >> >> If different functions are desired:
>> > >> >>
>> > >> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
>> > >> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
>> > >> >>call_user();
>> > >> >>EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on
>> clean
>> > >> >> exit
>> > >> >>another_cb(ctx);
>> > >> >>
>> > >> >> This is recommended if you expose ecore_thread to your users. If
>> you
>> > >> >> don't, then you do not need to do anything.
>> > >> >
>> > >> >
>> > >> > pthread_cancel did (does?) not exist on Android, by design choice.
>> bionic
>> > >> > isn't posix in that regard.
>> > >> > One way or another, I remember that using cancel is actually quite
>> hard,
>> > >> > because you need to be very careful about the cleanup.
>> > >> >
>> > >> > So I wonder if adding cancel like pthread here is the best choice?
>> > >> > Note that I understand the need and don't have any good alternative
>> :)
>> > >>
>> > >> Hi jpeg, thanks for letting me know.
>> > >>
>> > >> When we port to bionic we should then take one choice:
>> > >>
>> > >>  - let the thread hang there for a while, the new code I'm doing based
>> > >> on this concept shouldn't break, it will just consume few more
>> > >> resources for a while. (== #ifdef)
>> > >
>> > > i'd say do this all the time. cancellation otherwise is way too hard
>> AND its
>> > > non-portable. this is an api in eina that is non-portable and that
>> means we
>> > > have to try make it work on other platforms... if we keepit.
>> >
>> > by default the thread cancellation is disabled. You have to manually
>> > enable that and live with the pain, If you wish.
>> >
>> > I've used new efl_net code to test that, simulate what our users that
>> > loves thread would do... indeed it simplifies the code a lot to use a
>> > thread and do procedural programming (see ecore_con.c, socks stuff).
>> > The single detail to remember is to EINA_THREAD_CLEANUP_PUSH()/POP()
>> > and take care to not return in the middle, since it wouldn't execute
>> > the POP(EINA_TRUE) -- if you want to always cleanup.
>> >
>> > The portability part can be done, like vlc did. And that is said to
>> > work on Windows, seems Android is the only one not doing it.
>>
>
> Funny you would mention VLC.

easy... your email + google pthread_cancel for that project led me to
that code :-)


> The first implementation of vlc_thread_cancel
> on Android relied on a signal which would hopefully interrupt the blocking
> syscall in the thread to cancel. From my memories, this basically just did
> the job. Not sure which drawbacks it had effectively, but at the time, Remi
> had mentionned using futex instead.
>
> The current code uses futex indeed. What I can't figure out is how this
> interrupts blocking syscalls.
> Honestly I don't understand how that code works now :( If someone can
> enlighten me?

I guess it doesn't... are you sure it preempts the cancelled thread at
some point (be a cancellation point or some random if using
asynchronous)?

src/misc/threads.c seems to be the only user of that infrastructure
and it will insert explicit "testcancel" in some cancellation points
while sleeping. I guess if you do a blocking I/O you'll wait for that
forever.



> I also don't get how syscalls are interrupted on Windows.

it seems they provide an API to interrupt some I/O calls
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363794(v=vs.85).aspx


>> not portable to android. the problem is we have an eina thread api that is
>> not
>> portable. this is not an internal implementation detail. it's a public api
>> that
>> is not portable. no. no non-portable api's anymore. DEFINITELY if 

Re: [E-devel] Efl.Net and libproxy

[Simon Lees]

On 09/21/2016 12:33 AM, Gustavo Sverzut Barbieri wrote:
> On Tue, Sep 20, 2016 at 11:43 AM, Simon Lees  wrote:
>>
>>
>> On 09/20/2016 02:24 PM, Carsten Haitzler (The Rasterman) wrote:
>>> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
>>>  said:
>>>
 On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
 wrote:
> On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> Hi all,
>>
>> Today I did commit support for libproxy in ecore_con's new API,
>> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
>> (implicit from HTTP).
>
> ummm i just am looking now (i have a lot of catching up to do). can you 
> undo
> the changes to configure.ac and make this a dlopen/dlsym approach? well 
> use
> eina_module. look a the old curl eina_module approach. look at what i did 
> in
> ecore_audio too. in fact i need to look over all the efl net code, but you
> want to use emile for ssl stuff and eina_module for curl too there too (i
> haven't looked yet). there are very good reasons to do all of this.

 I've checked what you did for curl, since I use that and need more symbols.

 my question and concern are just:
  - not being able to compile without libproxy. If we always detect,
 should we remove --enable-libproxy from configure.ac?
>>>
>>> yes. it moves to runtime not compile-time. several reasons:
>>>
>>> 1. makes compiling simpler. people dont have to find dependencies and those
>>> -dev/devel pkgs too. if they add libproxy later after building efl magically
>>> the feature works without a rebuild.
>>
>> No no no, just Never that is about the most evil thing you can do if
>> there is no configure check distro's won't know that it should be pulled
>> in as a dependency and you will end up with different behavior on
>> different machines because one has a completely unrelated package
>> installed which also installed the dependency.
>>
>> Keep the ./configure check, add a --disable-libproxy flag for those that
>> don't want to go find it and sure after that dlopen it or whatever. But
>> the #1 priority should be making sure that distro packagers don't screw
>> it up because after all in a ideal world thats how most people should
>> get efl, sure make it easy enough for anyone to compile but don't make
>> it easier for distros to shoot there users in the foot by not realising
>> theres a extra dependency that probably should be pulled in. Unless of
>> course libproxy is not useful on a normal Linux distro and will only
>> ever be used in embedded contexts.
> 
> Simon, although I do understand your PoV -- packaging -- Raster is
> right and is concerned about runtime impact on non-users.
> 
> If you link to a library, particularly one that has a huge dep graph
> like libproxy, you end pulling too much and impacting everyone... even
> if that's not used.
> 

So how big in filesize are we talking about? if the distro ships
libproxy and isn't slackware it will take care of the dependency graph
on its own, if the distro doesn't have it the packager / user can then
just pass the --disable flag when building. "Large dependency chain"
shouldn't really be an argument distro's handle this fine.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efl.Net and libproxy

[The Rasterman]

On Tue, 20 Sep 2016 19:12:57 -0300 Gustavo Sverzut Barbieri
 said:

> damn raster... I had to do so I could check.
> 
> dlopen -> in git.
> 
> server and libproxy.so wrapper, attached with the basics, I'm not
> doing all the cumbersome details to get a single process running and
> spawn it from libproxy.so wrapper without a race condition.

there is no race.

connect. if connect fail, spawn, set timer to connect every 0.1 sec until
successful.

there is no race. first daemon spawned that binds to the socket wins. every
other one will fail and exit. there is no race to deal with as the bind does
the job for the daemon - first one in wins and the rest fail.

> I'd simplify all of that by using dbus with acquiring a name in the
> session bus and let that entity control it. Also would let the dbus
> daemon set isolation, like not inheriting current processes limits,
> namespaces and all.

no it isn't any easier with dbus. see above. this is what efreetd does not. its
REALLyYsimple and race-free.

> however as you dislike that, be my guest :-D
> 
>  gcc -o efl-proxy-resolver libproxy-efl-server.c `pkg-config --cflags
> --libs ecore eina efl eo libproxy-1.0`
>  gcc -shared -o libproxy-efl.so libproxy-efl.c `pkg-config --cflags
> eina` -lpthread

why did you do both a client exe and a server? just need the server... the
client copnnect/talk is in efl.net :) if you use efl.net like ecore_con it'd do
the XDG_RUNTIME_DIR for you for user local sockets (unless they are full path).
yuou just should have re-use efl.net inside there.

> (note libproxy.so doesn't link with eina)
> 
> EINA_LOG_LEVELS=efl-proxy-resolver:4 ./efl-proxy-resolver &
> LD_PRELOAD=libproxy-efl.so proxy http://google.com
> 
> /usr/bin/proxy is a test tool provided by libproxy. the server should
> print it's serving requests.
> 
> 
> On Tue, Sep 20, 2016 at 11:59 AM, Gustavo Sverzut Barbieri
>  wrote:
> > On Tue, Sep 20, 2016 at 1:54 AM, Carsten Haitzler 
> > wrote:
> >> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
> >>  said:
> >>
> >>> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
> >>> wrote:
> >>> > On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
> >>> >  said:
> >>> >
> >>> >> Hi all,
> >>> >>
> >>> >> Today I did commit support for libproxy in ecore_con's new API,
> >>> >> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
> >>> >> (implicit from HTTP).
> >>> >
> >>> > ummm i just am looking now (i have a lot of catching up to do). can you
> >>> > undo the changes to configure.ac and make this a dlopen/dlsym approach?
> >>> > well use eina_module. look a the old curl eina_module approach. look at
> >>> > what i did in ecore_audio too. in fact i need to look over all the efl
> >>> > net code, but you want to use emile for ssl stuff and eina_module for
> >>> > curl too there too (i haven't looked yet). there are very good reasons
> >>> > to do all of this.
> >>>
> >>> I've checked what you did for curl, since I use that and need more
> >>> symbols.
> >>>
> >>> my question and concern are just:
> >>>  - not being able to compile without libproxy. If we always detect,
> >>> should we remove --enable-libproxy from configure.ac?
> >>
> >> yes. it moves to runtime not compile-time. several reasons:
> >>
> >> 1. makes compiling simpler. people dont have to find dependencies and those
> >> -dev/devel pkgs too. if they add libproxy later after building efl
> >> magically the feature works without a rebuild.
> >> 2. speed up startup time with less linking going on for apps especially for
> >> features they may never use
> >> 3. saves memory - symbol tables and dirtying private pages to do the symbol
> >> fixups is expensive. i nuked like 320k or so before 1.18 release of actual
> >> real memory usage that was dirty pages from rarely used libraries.features.
> >> it's expensive and so only load in if/when needed to save this cost. this
> >> cost is private pages PER PROCESS using efl so it multiples and is not a
> >> one-off cost.
> >> 4. the idea of isolating such costs into a proxy daemon/process probably
> >> is a good thing and that saves adding the above cost for any process then
> >> needing to do proxy pac file parsing etc. and isolates the cost into a
> >> single daemon.
> >
> > I was asking if we should offer a way to not even try runtime detection.
> >
> >
> >>>  - I ask the above because libproxy is a monster, it will pull in a JS
> >>> loader, glib, C++... all of that, per process. If using pacrunner
> >>> (from connman guys) you can just link with libdbus, less bad.
> >>
> >> in GENERAL go for a dlopen(eina_module) style approach, BUT if a daemon
> >> makes sense, then do that.
> >
> > It's not something that excludes the other. Actually the opposite if
> > we do the proper way.
> >
> >  - efl does libproxy dlopen, so doesn't link to that library (simple
> > API but 

Re: [E-devel] [EGIT] [core/efl] master 01/01: edje edje_cc_out: use strncpy().

[Gustavo Sverzut Barbieri]

> +   int key_len = keyl + 1;
> +   key = alloca(key_len);
> if (!key) return;
> -   strcpy(key, prefix);
> +   strncpy(key, prefix, key_len);

as per other comments, memcpy() to shut up coverity. also alloca()
will never return NULL... you can remove that if (!key)



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: edje edje_embryo: use strncpy().

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 3:04 AM, ChunEon Park  wrote:
> hermet pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=06bd8dcf330fe31891475c92aa340d4886f47e2b
>
> commit 06bd8dcf330fe31891475c92aa340d4886f47e2b
> Author: Hermet Park 
> Date:   Wed Sep 21 15:03:11 2016 +0900
>
> edje edje_embryo: use strncpy().
>
> This change is not meaningful but avoids an annoying coverity detection.
> ---
>  src/lib/edje/edje_embryo.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/lib/edje/edje_embryo.c b/src/lib/edje/edje_embryo.c
> index bb46310..c09c3ff 100644
> --- a/src/lib/edje/edje_embryo.c
> +++ b/src/lib/edje/edje_embryo.c
> @@ -1553,10 +1553,9 @@ _edje_embryo_fn_get_text(Embryo_Program *ep, 
> Embryo_Cell *params)
>}
>  else
>{
> - char *ss;
> -
> - ss = alloca(strlen(s) + 1);
> - strcpy(ss, s);
> + int size = strlen(s) + 1;
> + char *ss = alloca(size);
> + strncpy(ss, s, size);


strlcpy(), but really, just dismiss this one in covertity... is it
dumb? We're alloca(strlen(s) + 1), how would it fail the size?

alternatively you can replace this with memcpy(ss, s, size), at least
it's faster.

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: edje/edje_cc: use strncpy() instead of strcpy().

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 1:32 AM, ChunEon Park  wrote:
> hermet pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=ab1a72f5e7df6fe0adef54bdcddd9867a2ebe3a6
>
> commit ab1a72f5e7df6fe0adef54bdcddd9867a2ebe3a6
> Author: Hermet Park 
> Date:   Wed Sep 21 13:30:44 2016 +0900
>
> edje/edje_cc: use strncpy() instead of strcpy().
>
> strncpy() is better for security.
> Also, this change avoids annoying coverity detection.
> ---
>  src/bin/edje/edje_cc_parse.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/bin/edje/edje_cc_parse.c b/src/bin/edje/edje_cc_parse.c
> index 525c71d..efabe22 100644
> --- a/src/bin/edje/edje_cc_parse.c
> +++ b/src/bin/edje/edje_cc_parse.c
> @@ -391,7 +391,7 @@ next_token(char *p, char *end, char **new_p, int *delim)
>   l = sscanf(tmpstr, "%*s %i \"%[^\"]\"", , fl);
>   if (l == 2)
> {
> -  strcpy(file_buf, fl);
> +  strncpy(file_buf, fl, sizeof(file_buf));
>line = nm;
>file_in = file_buf;
> }


the proper function to call is eina_strlcpy(), it will use strlcpy()
if available, otherwise will ensure the nul byte.



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/enlightenment] master 01/01: Update wayland readme file

[Christopher Michael]

devilhorns pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=1f43764db0e493d13245444bc4830ec4f11e8479

commit 1f43764db0e493d13245444bc4830ec4f11e8479
Author: Chris Michael 
Date:   Wed Sep 21 08:07:15 2016 -0400

Update wayland readme file

Signed-off-by: Chris Michael 
---
 README.wayland | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.wayland b/README.wayland
index 600d55a..da0be0b 100644
--- a/README.wayland
+++ b/README.wayland
@@ -76,7 +76,7 @@ a Wayland session. Simply start as usual:
 If you have a separate configuration profile that you would like to use,
 you can tell Enlightenment to use that when you start it:
 
-  dbus-launch enlightenment_start -profile 
+  enlightenment_start -profile 
 
 To run a wayland session inside x11, export E_WL_FORCE=x11 before starting
 enlightenment.

-- 

[EGIT] [apps/epour] master 01/01: Allow action menu to be activated by right click

[Kai Huuhko]

kuuko pushed a commit to branch master.

http://git.enlightenment.org/apps/epour.git/commit/?id=0cfc9a8653b9f586f258b09592dabc61238f39ba

commit 0cfc9a8653b9f586f258b09592dabc61238f39ba
Author: Kai Huuhko 
Date:   Wed Sep 21 14:50:32 2016 +0300

Allow action menu to be activated by right click
---
 epour/gui/__init__.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/epour/gui/__init__.py b/epour/gui/__init__.py
index a060bbf..057c2af 100644
--- a/epour/gui/__init__.py
+++ b/epour/gui/__init__.py
@@ -170,6 +170,7 @@ class MainInterface(object):
 itm.focus = True
 
 tlist.callback_activated_add(item_activated_cb)
+tlist.callback_clicked_right_add(item_activated_cb)
 tlist.show()
 
 mbox.pack_end(tlist)

-- 

[EGIT] [core/enlightenment] master 01/01: protect against non-nul terminated string from mmap in filepreview

[Carsten Haitzler]

raster pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=5861d9bef949c64cbc7ddad31b4ac2cc70bb6440

commit 5861d9bef949c64cbc7ddad31b4ac2cc70bb6440
Author: Carsten Haitzler (Rasterman) 
Date:   Wed Sep 21 20:18:01 2016 +0900

protect against non-nul terminated string from mmap in filepreview

this should address 2nd gdb bt and fix T4543

@fix
---
 src/bin/e_widget_filepreview.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/bin/e_widget_filepreview.c b/src/bin/e_widget_filepreview.c
index 2602895..1f91073 100644
--- a/src/bin/e_widget_filepreview.c
+++ b/src/bin/e_widget_filepreview.c
@@ -931,8 +931,13 @@ _e_wid_fprev_preview_txt_map_success(void *data, Eio_File 
*handler EINA_UNUSED,
char *msg;
Evas_Coord mw, mh;
 
+   msg = malloc(length + 1);
+   if (!msg) return;
+   strncpy(msg, map, length);
+   msg[length] = 0;
buf = eina_strbuf_new();
-   eina_strbuf_append_length(buf, map, length);
+   eina_strbuf_append_length(buf, msg, length);
+   free(msg);
msg = evas_textblock_text_utf8_to_markup(NULL, eina_strbuf_string_get(buf));
eina_strbuf_reset(buf);
 

-- 

[EGIT] [core/enlightenment] master 01/01: remove extraneous recalc trigger when deleting a gadget

[Mike Blumenkrantz]

discomfitor pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=0074c1ca27b716f0fbe26e0e3bbbe50d93808a87

commit 0074c1ca27b716f0fbe26e0e3bbbe50d93808a87
Author: Mike Blumenkrantz 
Date:   Wed Sep 21 07:12:00 2016 -0400

remove extraneous recalc trigger when deleting a gadget

CID 1362898
---
 src/bin/e_gadget.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/bin/e_gadget.c b/src/bin/e_gadget.c
index 7b68487..ee44819 100644
--- a/src/bin/e_gadget.c
+++ b/src/bin/e_gadget.c
@@ -758,7 +758,6 @@ _gadget_menu_remove(void *data, E_Menu *m EINA_UNUSED, 
E_Menu_Item *mi EINA_UNUS
E_Gadget_Config *zgc = data;
 
_gadget_remove(zgc);
-   evas_object_smart_need_recalculate_set(zgc->site->layout, 1);
e_config_save_queue();
 }
 

-- 

[EGIT] [core/efl] master 02/03: elm: progressbar: hide unit if unit_format_func is invalid

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=1f00c9a26e1b9064ef38994761934a7ed85d9609

commit 1f00c9a26e1b9064ef38994761934a7ed85d9609
Author: Stefan Schmidt 
Date:   Wed Sep 21 10:41:58 2016 +0200

elm: progressbar: hide unit if unit_format_func is invalid

In commit 03882d558824f657f5c5a54fcd2d632eafeafd87 this was introduced but 
in
the end the visible signal was send in all cases. This looks like an 
oversight
to me. Fixed.
---
 src/lib/elementary/elm_progressbar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/elementary/elm_progressbar.c 
b/src/lib/elementary/elm_progressbar.c
index 57f33bb..9f92ca7 100644
--- a/src/lib/elementary/elm_progressbar.c
+++ b/src/lib/elementary/elm_progressbar.c
@@ -573,7 +573,7 @@ elm_progressbar_unit_format_function_set(Elm_Progressbar 
*obj, progressbar_func_
sd->unit_format_func = func;
sd->unit_format_free = free_func;
sig = (func) ? "elm,state,units,visible" : "elm,state,units,hidden";
-   elm_layout_signal_emit(obj, "elm,state,units,visible", "elm");
+   elm_layout_signal_emit(obj, sig, "elm");
edje_object_message_signal_process(wd->resize_obj);
 
_units_set(obj);

-- 

[EGIT] [core/efl] master 01/03: evas: model_save: remove unused label after error handling change

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=9079d2b575fad671ee85c7596830d08903bdcef5

commit 9079d2b575fad671ee85c7596830d08903bdcef5
Author: Stefan Schmidt 
Date:   Wed Sep 21 10:29:18 2016 +0200

evas: model_save: remove unused label after error handling change

In commit 8272d1492796657978c5591971768d37d4e15a7e the error handling was
moved upwards and the need for the goto label removed. Catching up here and
removing the label as well.
---
 src/modules/evas/model_savers/eet/evas_model_save_eet.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/modules/evas/model_savers/eet/evas_model_save_eet.c 
b/src/modules/evas/model_savers/eet/evas_model_save_eet.c
index c752dd3..d659e41 100644
--- a/src/modules/evas/model_savers/eet/evas_model_save_eet.c
+++ b/src/modules/evas/model_savers/eet/evas_model_save_eet.c
@@ -199,7 +199,6 @@ evas_model_save_file_eet(const Evas_Canvas3D_Mesh *mesh,
   EINA_TRUE);
eet_close(ef);
 
- on_error:
_evas_canvas3d_eet_file_free(eet_file);
 
eet_shutdown();

-- 

[EGIT] [core/efl] master 03/03: tests: elm_win: fix compiler warning about signed vs. unsigned comparison

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=a24734d80ac6902eb85e8c90ad98208eb948c779

commit a24734d80ac6902eb85e8c90ad98208eb948c779
Author: Stefan Schmidt 
Date:   Wed Sep 21 10:56:36 2016 +0200

tests: elm_win: fix compiler warning about signed vs. unsigned comparison

The variable i only goes from 0 to 4 here but it gets compared against a 
normal
int so we make sure i also is a normal int.
---
 src/tests/elementary/elm_test_win.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/tests/elementary/elm_test_win.c 
b/src/tests/elementary/elm_test_win.c
index 49cc6db..df0d8cf 100644
--- a/src/tests/elementary/elm_test_win.c
+++ b/src/tests/elementary/elm_test_win.c
@@ -258,7 +258,8 @@ _inputs_timer2_cb(void *data)
Efl_Input_Pointer *ptr;
Eina_Iterator *it;
Eo *win = data;
-   size_t i = 0, cnt = 0;
+   size_t cnt = 0;
+   int i = 0;
 
it = efl_input_pointer_iterate(win, 0);
EINA_ITERATOR_FOREACH(it, ptr)
@@ -319,7 +320,8 @@ _inputs_timer3_cb(void *data)
Efl_Input_Pointer *ptr;
Eina_Iterator *it;
Eo *win = data;
-   size_t i = 0, cnt = 0;
+   size_t cnt = 0;
+   int i = 0;
 
it = efl_input_pointer_iterate(win, 0);
EINA_ITERATOR_FOREACH(it, ptr)

-- 

[EGIT] [tools/eflete] master 01/01: Revert "ewe_ruler: don't set labels text if marker position was changed"

[Andrii Kroitor]

rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=84b6d0b1d298e3c5c5273a11cc5e92c1c94c623a

commit 84b6d0b1d298e3c5c5273a11cc5e92c1c94c623a
Author: Andrii Kroitor 
Date:   Tue Sep 20 18:53:54 2016 +0300

Revert "ewe_ruler: don't set labels text if marker position was changed"

This reverts commit c8c551619700ee2c29ce09bfb5bb0e0fe40df4be.

Because of this commit labels are not updated when scrolling ruler.
---
 src/lib/ewe_ruler.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/lib/ewe_ruler.c b/src/lib/ewe_ruler.c
index 552f685..c513519 100644
--- a/src/lib/ewe_ruler.c
+++ b/src/lib/ewe_ruler.c
@@ -658,6 +658,7 @@ _ewe_ruler_marker_relative_set(Eo *obj,
  }
marker->rel_position = pos;
 
+   sd->text_changed = EINA_TRUE;
evas_object_smart_changed(obj);
return EINA_TRUE;
 }
@@ -698,6 +699,7 @@ _ewe_ruler_marker_absolute_set(Eo *obj,
  }
marker->abs_position = pos;
 
+   sd->text_changed = EINA_TRUE;
evas_object_smart_changed(obj);
return EINA_TRUE;
 }
@@ -736,6 +738,7 @@ _ewe_ruler_marker_visible_set(Eo *obj EINA_UNUSED,
  evas_object_hide(marker->obj);
else if (sd->ruler_visible)
  evas_object_show(marker->obj);
+   sd->text_changed = EINA_TRUE;
evas_object_smart_changed(obj);
return EINA_TRUE;
 }
@@ -967,8 +970,10 @@ _ewe_ruler_efl_canvas_group_group_calculate(Eo *obj 
EINA_UNUSED,
 sd->position_changed = EINA_FALSE;
  }
if (sd->text_changed)
- _set_labels(sd);
-   _place_markers(sd);
+ {
+_set_labels(sd);
+_place_markers(sd);
+ }
 }
 
 EOLIAN static Elm_Theme_Apply

-- 

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 19/09/16 23:33, Cedric BAIL wrote:
> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>> against it.
>
> There was a thread weeks ago. You indeed didn't take part of that
> discussion, but everyone else involved in that thread was ok. Actually
> the discussion evolved more into a what else to merge in. So their was
> an agreement before this email.

Sorry, I missed that thread. What was the topic?

>
>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>> good thing. This makes our infrastructure easier to test.
>
> Please define "clean" as it is a bit abstract to me here. What I am
> looking for here is the minimal set of component I need to have
> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
> you could do C without the C library, but would you ?

You are right. Let's merge in Eina too.

Or without joking: people have been using Eo without ecore and without 
Efl.Object. One example is Mike in E (reverted now because Eo was 
undeclared stable). You'll probably end up using Ecore in the same app, 
but again, everything you can say here you can say about Eina too.

By "clean" I mean "isolated" or "untainted by its users up the stack". 
(see next comment for more info).

>
> I think that your disagreement about merging is only and just because
> you do not want to make asynchronous request a core feature of EFL.
> The rest is mostly rhetoric. Could you please explain why you have so
> much resistance to it being rolled into more place in efl ?

That is exactly the reason (was I hiding it?), but not only, and one 
example of not "clean".

A while back I was giving you some flack for not writing tests for a 
component of the EFL and cited Eo as an example of getting high test 
coverage. You then laughed it off and said something in the lines of 
"it's easier to test because it's smaller and not async" or something 
like that.
**THAT IS EXACTLY MY POINT.**
 From my experience (and I guess the industry's collective experience), 
having small separate units make quality assurance easier, units more 
testable (because you can easily unit test) and the code easier to maintain.

>
> As for the tests, I really don't like our eo tests. They are not
> really testing a clean scenario that is possible to guess, but just a
> mismatch of everything into one big C file. When something break
> there, you can't just rely on the name of the tests, or reading
> quickly the code to guess what's happening. Nop. You have to get
> hundred of lines of tests with little logical connection to each
> other. I have found them less than useful when developping (And some
> times buggy, as instead of testing a scenario that makes sense, they
> were just testing that the code was matching the tests). So I don't
> get your argument of making it easier to tests.

The Eo suite is a mixture of success-scenario, failure-scenario and 
regression testing.
Success scenario: making sure an expected scenario works.
Failure scenario: making sure an expected scenario fails.
regression testing: making sure what we have stays the same.

Success scenarios would rarely need changing, only if you change 
something drastic or make the code more strict. Failure would need to 
change a bit more often, depending on how strict we make the code. 
Regression testing will probably change often, as they are there so you 
*understand* that you are changing behaviour, even if undocumented.

I'm not aware of any buggy tests, but do let me know if you find one, 
and while at it, if possible, try and fix them.

You have to also remember, these tests have been with us through a few 
Eo rewrites. They have been here from day 1. :)

>
>> If you mean just compile them together, then there's no point in it.
>> I know why you want to do it, you want to do it because you put Efl.Future
>> inside libeo.so, but the correct thing to do is probably not to put it
>> there.
>
> I don't want to just compile them together. I want to merge there
> headers. Make it just one library. Make efl.object, efl.future and
> efl.loop one core. Obviously because I want to see efl as providing a
> core asynchronous library with defined pattern. One asynchronous
> pattern is "events", which is like an UDP broadcast (default
> behavior)/multicast (with effort) solution. Efl.Future is more the
> equivalent of a TCP connection. I think providing one without the
> other is going to push for a world of broadcast solution which is not
> always the right pattern. Maybe we should remove events support from
> Eo to avoid this problem.

Of course also merging the headers. What I meant is: you want a cycle 
dep. Mutual reliance.

It's not really a broadcast, because you need to register to listen.

Removing events from Eo is not the way to go. If you want an async 
pattern, do it up the stack (even eolian) and encourage it there. People 
who use the loop will 

[EGIT] [core/efl] master 01/01: evas: remove unnecessary check for clip coords.

[Sungtaek Hong]

hermet pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=57c4d83b2e0de0a1a9e939f7762c1961e47cf74c

commit 57c4d83b2e0de0a1a9e939f7762c1961e47cf74c
Author: Sungtaek Hong 
Date:   Wed Sep 21 17:40:53 2016 +0900

evas: remove unnecessary check for clip coords.

Summary: (dst_clip_w <= 0 || dst_clip_h <= 0) is already checked.

Reviewers: jpeg, cedric, Hermet

Reviewed By: Hermet

Subscribers: conr2d

Differential Revision: https://phab.enlightenment.org/D4303
---
 src/lib/evas/common/evas_scale_sample.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/lib/evas/common/evas_scale_sample.c 
b/src/lib/evas/common/evas_scale_sample.c
index 008e43d..71a805e 100644
--- a/src/lib/evas/common/evas_scale_sample.c
+++ b/src/lib/evas/common/evas_scale_sample.c
@@ -553,7 +553,6 @@ scale_rgba_in_to_out_clip_sample_internal(RGBA_Image *src, 
RGBA_Image *dst,
  }
if (dst_region_w <= 0) return EINA_FALSE;
if (src_region_w <= 0) return EINA_FALSE;
-   if (dst_clip_w <= 0) return EINA_FALSE;
if (dst_clip_x >= dst_w) return EINA_FALSE;
if (dst_clip_x < dst_region_x)
  {
@@ -582,7 +581,6 @@ scale_rgba_in_to_out_clip_sample_internal(RGBA_Image *src, 
RGBA_Image *dst,
  }
if (dst_region_h <= 0) return EINA_FALSE;
if (src_region_h <= 0) return EINA_FALSE;
-   if (dst_clip_h <= 0) return EINA_FALSE;
if (dst_clip_y >= dst_h) return EINA_FALSE;
if (dst_clip_y < dst_region_y)
  {

-- 

[EGIT] [tools/eflete] master 01/01: tab_home: fix a segment fault

[Jaehwan Kim]

jaehwan pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=c4b141feff6625c2750ff8943f26b1e42e6c0be6

commit c4b141feff6625c2750ff8943f26b1e42e6c0be6
Author: Jaehwan Kim 
Date:   Wed Sep 21 17:07:29 2016 +0900

tab_home: fix a segment fault
---
 src/bin/ui/tab_home_import_edj.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/bin/ui/tab_home_import_edj.c b/src/bin/ui/tab_home_import_edj.c
index edb5101..4e299fd 100644
--- a/src/bin/ui/tab_home_import_edj.c
+++ b/src/bin/ui/tab_home_import_edj.c
@@ -708,16 +708,15 @@ _tab_import_edj_data_set(const char *name, const char 
*path, const char *edj, co
 if (!item)
   {
  item = elm_genlist_first_item_get(tab_edj.genlist);
- do
+ while (item)
{
   node = elm_object_item_data_get(item);
   if (!strcmp(node->name, "elm/"))
 break;
   item = elm_genlist_item_next_get(item);
}
- while (item);
   }
-if (node->list)
+if (node && node->list)
   {
  EINA_LIST_FOREACH(node->list, l1, sub)
  {

-- 

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 20/09/16 05:14, Gustavo Sverzut Barbieri wrote:
> On Mon, Sep 19, 2016 at 7:33 PM, Cedric BAIL  wrote:
>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>>> against it.
>>
>> There was a thread weeks ago. You indeed didn't take part of that
>> discussion, but everyone else involved in that thread was ok. Actually
>> the discussion evolved more into a what else to merge in. So their was
>> an agreement before this email.
>>
>>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>>> good thing. This makes our infrastructure easier to test.
>>
>> Please define "clean" as it is a bit abstract to me here. What I am
>> looking for here is the minimal set of component I need to have
>> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
>> you could do C without the C library, but would you ?
>>
>> I think that your disagreement about merging is only and just because
>> you do not want to make asynchronous request a core feature of EFL.
>> The rest is mostly rhetoric. Could you please explain why you have so
>> much resistance to it being rolled into more place in efl ?
>
> [...]
>
>> I don't want to just compile them together. I want to merge there
>> headers. Make it just one library. Make efl.object, efl.future and
>> efl.loop one core. Obviously because I want to see efl as providing a
>> core asynchronous library with defined pattern. One asynchronous
>> pattern is "events", which is like an UDP broadcast (default
>> behavior)/multicast (with effort) solution. Efl.Future is more the
>> equivalent of a TCP connection. I think providing one without the
>> other is going to push for a world of broadcast solution which is not
>> always the right pattern. Maybe we should remove events support from
>> Eo to avoid this problem.
>
> +1 fully agree with Cedric's rationale. Eo's purpose should be
> solely to serve Efl's use cases, which means asynchronous event driven
> programming.

I'll reply to cedric in a moment, but in the meanwhile:

>
> promise/future should be first-class citizen... as well as iterator
> and the likes. There is a start already, but refinement is really
> needed, like returning an iterator should handle warn_unused, free,
> own... Promise should have its own callback signature, simplified for
> the user.
>

They can, be, but they will just be provided by Eo. There's no need for 
any special treatment in Eo.

Promise signature: you don't need to do it in Eo. I mean, you can add a 
special type in Eolian, but Eo itself need not be aware. Also, I disagree.

> AND if possible, make eolian or a new tool to handle connections for
> us, if it was easy to declare objects with composition of
> events/promises, it would save us lots of typing and errors.
>
>

I'm not sure what you meant here.

--
Tom

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 02/02: elm_config: add null check before usage

[Thiep Ha]

thiep pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=3689a803dbfe1297e706d2fbfde239d641652de1

commit 3689a803dbfe1297e706d2fbfde239d641652de1
Author: Thiep Ha 
Date:   Wed Sep 21 16:54:09 2016 +0900

elm_config: add null check before usage
---
 src/lib/elementary/elm_config.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/lib/elementary/elm_config.c b/src/lib/elementary/elm_config.c
index af8394b..0fe52b8 100644
--- a/src/lib/elementary/elm_config.c
+++ b/src/lib/elementary/elm_config.c
@@ -3772,9 +3772,10 @@ _translation_init(void)
 * en_/C where translating only parts of the interface make some
 * sense).
 */
-   _elm_config->translate = !(strcmp (cur_dom, "messages") &&
- !*trans_comment && strncmp (msg_locale, "en_", 3) &&
- strcmp (msg_locale, "C"));
+   if (msg_locale)
+ _elm_config->translate = !(strcmp (cur_dom, "messages") &&
+   !*trans_comment && strncmp (msg_locale, "en_", 3) &&
+   strcmp (msg_locale, "C"));
/* Get RTL orientation from system */
if (_elm_config->translate)
  {

-- 

[EGIT] [core/efl] master 01/02: elm_atspi: remove redundant null checking

[Thiep Ha]

thiep pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=401706351d38cbfd6fa7e677af387400a888932a

commit 401706351d38cbfd6fa7e677af387400a888932a
Author: Thiep Ha 
Date:   Wed Sep 21 16:49:12 2016 +0900

elm_atspi: remove redundant null checking

The type is always _ADDED or _REMOVED, therefore atspi_desc
is always "add" or "remove"; no need to have null checking for it.
---
 src/lib/elementary/elm_atspi_bridge.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/lib/elementary/elm_atspi_bridge.c 
b/src/lib/elementary/elm_atspi_bridge.c
index fbb08a3..c6c1b77 100644
--- a/src/lib/elementary/elm_atspi_bridge.c
+++ b/src/lib/elementary/elm_atspi_bridge.c
@@ -3968,12 +3968,6 @@ _children_changed_signal_send(void *data, const 
Efl_Event *event)
 break;
 }
 
-   if (!atspi_desc)
- {
-efl_event_callback_stop(event->object);
-return;
- }
-
_bridge_signal_send(data, event->object, ATSPI_DBUS_INTERFACE_EVENT_OBJECT,

&_event_obj_signals[ATSPI_OBJECT_EVENT_CHILDREN_CHANGED], atspi_desc,
idx, 0, "(so)", 
eldbus_connection_unique_name_get(pd->a11y_bus), ev_data->child);

-- 

[EGIT] [core/efl] master 01/01: evas software_engine: ++safety code.

[ChunEon Park]

hermet pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=c998fd5ee7e90f1861aba6d4a44d8c0b5387bb61

commit c998fd5ee7e90f1861aba6d4a44d8c0b5387bb61
Author: Hermet Park 
Date:   Wed Sep 21 16:24:42 2016 +0900

evas software_engine: ++safety code.
---
 src/modules/evas/engines/software_generic/evas_engine.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/modules/evas/engines/software_generic/evas_engine.c 
b/src/modules/evas/engines/software_generic/evas_engine.c
index 62ad71a..2755b48 100644
--- a/src/modules/evas/engines/software_generic/evas_engine.c
+++ b/src/modules/evas/engines/software_generic/evas_engine.c
@@ -2869,6 +2869,7 @@ eng_image_map_surface_new(void *data EINA_UNUSED, int w, 
int h, int alpha)
 surface = evas_cache2_image_copied_data(evas_common_image_cache2_get(),
 w, h, NULL, alpha,
 EVAS_COLORSPACE_ARGB);
+if (!surface) return NULL;
 evas_cache2_image_pixels(surface);
 return surface;
  }
@@ -2876,6 +2877,7 @@ eng_image_map_surface_new(void *data EINA_UNUSED, int w, 
int h, int alpha)
surface = evas_cache_image_copied_data(evas_common_image_cache_get(), 
   w, h, NULL, alpha, 
   EVAS_COLORSPACE_ARGB);
+   if (!surface) return NULL;
evas_cache_image_pixels(surface);
return surface;
 }

-- 

Re: [E-devel] EFL interface, what's left to be done

[Jean-Philippe André]

Hi Cedric,

On 20 September 2016 at 06:05, Cedric BAIL  wrote:

> Hello everyone,
>
> So this email is going over what is left to be done to call EFL
> interface done. Most of this require still discussion also. Here it
> goes :
>
> - Merge Eo, Efl and Ecore
> - Make efl_uri_set/efl_file_set asynchronous
> - Convert Ecore_Exe to the new efl_io API
> - Fixup efl/interface/*.eo to all be in the correct namespace
> - Disable installation of evas/canvas/evas*.eo
> - Convert edje to become efl_canvas_layout
> - Update Edje with the new Text API
> - Convert elm_layout to become efl_ui_layout
> - Convert elm_widget to be an efl_ui_object of some sort
> - Update all efl data model to use efl_future/efl_promise
> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
> ideas)
> - There is still a large amount of .eo in elementary that are in elm
> namespace. This shouldn't be installed nor appear anywhere in the
> hierarchy.
> - Finish porting some of the widget to Efl.Ui namespace (photocam,
> index, entry, button, calendar, clock, menu, ...). This needs to be
> clarified with some pending patch in phab.
>
> This are quite a large todo list to be done with, hopefully it will...
>

- evas smart objects
Evas smart objects are a stable legacy API but their equivalent in EO is
horrible. Efl.Canvas.Group is not an acceptable replacement in its current
form. All the methods this class defines are poorly defined overrides over
the basic object functions (show, hide, etc...). I've started some work in
this direction but it's tedious and risky. The alternative is to have no
API for custom smart objects.

- elm_widget
elm widget was and still is an unstable / private API. I don't think
cleaning up this API is in the scope of our interfaces work, right now.

- text part API
Textblock now has a new shiny eo api but edje_object and elm_layout still
define _part_text_ APIs. This needs to be transformed to Efl.Part.

- efl.ui.window + elm_conformant
Ideally window should have merged in the features of conformant so we avoid
this extra awkward widget. Window was supposed to handle what conformant
does. The reality is that no work towards that goal has been done yet.

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

[Jean-Philippe André]

Hi Gustavo,

On 21 September 2016 at 07:11, Carsten Haitzler 
wrote:

> On Tue, 20 Sep 2016 12:17:50 -0300 Gustavo Sverzut Barbieri
>  said:
>
> > On Tue, Sep 20, 2016 at 11:18 AM, Carsten Haitzler  >
> > wrote:
> > > On Tue, 20 Sep 2016 08:16:21 -0300 Gustavo Sverzut Barbieri
> > >  said:
> > >
> > >> On Tue, Sep 20, 2016 at 5:51 AM, Jean-Philippe André <
> j...@videolan.org>
> > >> wrote:
> > >> > Hi Gustavo,
> > >> >
> > >> > On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri
> > >> >  wrote:
> > >> >
> > >> >> HEADS UP -- BINDINGS:
> > >> >>
> > >> >> If you wish to expose the new "cancellable" property, or cope with
> > >> >> naughty users or 3rd party deps that may call
> > >> >> pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register
> your
> > >> >> cleanup functions with:
> > >> >>
> > >> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> > >> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> > >> >>call_user();
> > >> >>EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean
> exit
> > >> >>
> > >> >> If different functions are desired:
> > >> >>
> > >> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> > >> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> > >> >>call_user();
> > >> >>EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on
> clean
> > >> >> exit
> > >> >>another_cb(ctx);
> > >> >>
> > >> >> This is recommended if you expose ecore_thread to your users. If
> you
> > >> >> don't, then you do not need to do anything.
> > >> >
> > >> >
> > >> > pthread_cancel did (does?) not exist on Android, by design choice.
> bionic
> > >> > isn't posix in that regard.
> > >> > One way or another, I remember that using cancel is actually quite
> hard,
> > >> > because you need to be very careful about the cleanup.
> > >> >
> > >> > So I wonder if adding cancel like pthread here is the best choice?
> > >> > Note that I understand the need and don't have any good alternative
> :)
> > >>
> > >> Hi jpeg, thanks for letting me know.
> > >>
> > >> When we port to bionic we should then take one choice:
> > >>
> > >>  - let the thread hang there for a while, the new code I'm doing based
> > >> on this concept shouldn't break, it will just consume few more
> > >> resources for a while. (== #ifdef)
> > >
> > > i'd say do this all the time. cancellation otherwise is way too hard
> AND its
> > > non-portable. this is an api in eina that is non-portable and that
> means we
> > > have to try make it work on other platforms... if we keepit.
> >
> > by default the thread cancellation is disabled. You have to manually
> > enable that and live with the pain, If you wish.
> >
> > I've used new efl_net code to test that, simulate what our users that
> > loves thread would do... indeed it simplifies the code a lot to use a
> > thread and do procedural programming (see ecore_con.c, socks stuff).
> > The single detail to remember is to EINA_THREAD_CLEANUP_PUSH()/POP()
> > and take care to not return in the middle, since it wouldn't execute
> > the POP(EINA_TRUE) -- if you want to always cleanup.
> >
> > The portability part can be done, like vlc did. And that is said to
> > work on Windows, seems Android is the only one not doing it.
>

Funny you would mention VLC. The first implementation of vlc_thread_cancel
on Android relied on a signal which would hopefully interrupt the blocking
syscall in the thread to cancel. From my memories, this basically just did
the job. Not sure which drawbacks it had effectively, but at the time, Remi
had mentionned using futex instead.

The current code uses futex indeed. What I can't figure out is how this
interrupts blocking syscalls.
Honestly I don't understand how that code works now :( If someone can
enlighten me?

I also don't get how syscalls are interrupted on Windows.


not portable to android. the problem is we have an eina thread api that is
> not
> portable. this is not an internal implementation detail. it's a public api
> that
> is not portable. no. no non-portable api's anymore. DEFINITELY if they
> completely fail based on platform. if its "its a bit slower on another
> platform
> as that feature doesnt exist so we emulate" then fine.
>
> we used to be linux/unix only. over the years we've had to become
> portable. now
> we have to make portable the top priority.
>
> if it's not portable then don't support it. deal with it some other way.



>
> > >>  - use pthread_kill() with an unused signal and use a signal
> > >> handler... this can be a full wrapper like the one in videolan.org,
> or
> > >> just to generate EINTR like I proposed in my first discussion.
> > >
> > > this would be a far better workaround. :)
> >
> > doesn't work on Windows :-(
>
> then hang until timeout hit. use another thread in the pool. :)
>

This assumes that the syscalls will timeout.

Anyhow. 

[EGIT] [core/efl] master 01/01: edje edje_cc_out: use strncpy().

[ChunEon Park]

hermet pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=6de3b2c5d36993cf3dbe94e8fbefd04043f91740

commit 6de3b2c5d36993cf3dbe94e8fbefd04043f91740
Author: Hermet Park 
Date:   Wed Sep 21 15:19:19 2016 +0900

edje edje_cc_out: use strncpy().

This change is not much meaningful but avoids an annoying coverity 
detection.
---
 src/bin/edje/edje_cc_out.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/bin/edje/edje_cc_out.c b/src/bin/edje/edje_cc_out.c
index 90a8e41..cf9a831 100644
--- a/src/bin/edje/edje_cc_out.c
+++ b/src/bin/edje/edje_cc_out.c
@@ -4036,9 +4036,10 @@ data_process_string(Edje_Part_Collection *pc, const char 
*prefix, char *s, void
int quote, escape;
 
keyl = strlen(prefix) + 2;
-   key = alloca(keyl + 1);
+   int key_len = keyl + 1;
+   key = alloca(key_len);
if (!key) return;
-   strcpy(key, prefix);
+   strncpy(key, prefix, key_len);
strcat(key, ":\"");
quote = 0;
escape = 0;

-- 

[EGIT] [core/efl] master 01/01: edje edje_embryo: use strncpy().

[ChunEon Park]

hermet pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=06bd8dcf330fe31891475c92aa340d4886f47e2b

commit 06bd8dcf330fe31891475c92aa340d4886f47e2b
Author: Hermet Park 
Date:   Wed Sep 21 15:03:11 2016 +0900

edje edje_embryo: use strncpy().

This change is not meaningful but avoids an annoying coverity detection.
---
 src/lib/edje/edje_embryo.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/lib/edje/edje_embryo.c b/src/lib/edje/edje_embryo.c
index bb46310..c09c3ff 100644
--- a/src/lib/edje/edje_embryo.c
+++ b/src/lib/edje/edje_embryo.c
@@ -1553,10 +1553,9 @@ _edje_embryo_fn_get_text(Embryo_Program *ep, Embryo_Cell 
*params)
   }
 else
   {
- char *ss;
-
- ss = alloca(strlen(s) + 1);
- strcpy(ss, s);
+ int size = strlen(s) + 1;
+ char *ss = alloca(size);
+ strncpy(ss, s, size);
  ss[params[3] - 1] = 0;
  SETSTR(ss, params[2]);
   }

--