[EGIT] [core/elementary] master 01/01: elm_conform.c: Added "virtualkeypad,size,changed" smart callback.

[Daniel Juyung Seo]

seoz pushed a commit to branch master.

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

commit cbd7446f0bf413ad821ac40703d2a2ca728758ef
Author: Daniel Juyung Seo 
Date:   Wed Oct 30 16:17:57 2013 +0900

elm_conform.c: Added "virtualkeypad,size,changed" smart callback.

When the virtualkeypad size is changed, applications get the notice.
Applications can do internal object calculation according to the exact 
virtualkeypad size.
This is useful when the exact size is important such as webkit usecase.
---
 ChangeLog | 4 
 NEWS  | 1 +
 src/lib/elm_conform.c | 7 +++
 src/lib/elm_conform.h | 3 +++
 4 files changed, 15 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index fbeecc7..e99d3fd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1727,3 +1727,7 @@
 2013-10-30  Amitesh Singh (_ami_)
 
 * image: Add support for "clicked" callback on Return/space/KP_Enter 
key press.
+
+2013-10-30  Daniel Juyung Seo (SeoZ)
+
+* conform: Added "virtualkeypad,size,changed" callback on 
virtualkeypad min size change.
diff --git a/NEWS b/NEWS
index 8481107..6876073 100644
--- a/NEWS
+++ b/NEWS
@@ -101,6 +101,7 @@ Additions:
* Add elm_fileselector_hidden_visible_set/get() to show or hide hidden 
files/directories.
* Add signals "spinner,drag,start" and "spinner,drag,stop" to the spinner 
widget.
* Add support for "clicked" callback on Return/space/KP_Enter key press for 
image.
+   * Add "virtualkeypad,size,changed" callback on virtualkeypad min size 
change for conformant.
 
 Improvements:
 
diff --git a/src/lib/elm_conform.c b/src/lib/elm_conform.c
index 9636ab8..cb00888 100644
--- a/src/lib/elm_conform.c
+++ b/src/lib/elm_conform.c
@@ -36,12 +36,14 @@ static const char SOFTKEY_PART[] = "elm.swallow.softkey";
 
 static const char SIG_VIRTUALKEYPAD_STATE_ON[] = "virtualkeypad,state,on";
 static const char SIG_VIRTUALKEYPAD_STATE_OFF[] = "virtualkeypad,state,off";
+static const char SIG_VIRTUALKEYPAD_SIZE_CHANGED[] = 
"virtualkeypad,size,changed";
 static const char SIG_CLIPBOARD_STATE_ON[] = "clipboard,state,on";
 static const char SIG_CLIPBOARD_STATE_OFF[] = "clipboard,state,off";
 
 static const Evas_Smart_Cb_Description _smart_callbacks[] = {
{SIG_VIRTUALKEYPAD_STATE_ON, ""},
{SIG_VIRTUALKEYPAD_STATE_OFF, ""},
+   {SIG_VIRTUALKEYPAD_SIZE_CHANGED, ""},
{SIG_CLIPBOARD_STATE_ON, ""},
{SIG_CLIPBOARD_STATE_OFF, ""},
{NULL, NULL}
@@ -166,6 +168,8 @@ _conformant_part_sizing_eval(Evas_Object *obj,
 
if (part_type & ELM_CONFORMANT_VIRTUAL_KEYPAD_PART)
  {
+Evas_Coord_Rectangle rect;
+
 #ifdef HAVE_ELEMENTARY_X
 if ((!_conformant_part_geometry_get_from_env
("ILLUME_KBD", &sx, &sy, &sw, &sh)) && (xwin))
@@ -189,6 +193,9 @@ _conformant_part_sizing_eval(Evas_Object *obj,
 DBG("[KEYPAD]: size(%d,%d, %dx%d).", sx, sy, sw, sh);
 _conformant_part_size_hints_set
   (obj, sd->virtualkeypad, sx, sy, sw, sh);
+
+rect.x = sx; rect.y = sy; rect.w = sw; rect.h = sh;
+evas_object_smart_callback_call(obj, SIG_VIRTUALKEYPAD_SIZE_CHANGED, 
(void *)&rect);
  }
 
if (part_type & ELM_CONFORMANT_SOFTKEY_PART)
diff --git a/src/lib/elm_conform.h b/src/lib/elm_conform.h
index a491b95..e1187b5 100644
--- a/src/lib/elm_conform.h
+++ b/src/lib/elm_conform.h
@@ -28,6 +28,9 @@
  * (@since 1.8)
  * @li "virtualkeypad,state,off": if virtualkeypad state is switched to "off".
  * (@since 1.8) 
+ * @li "virtualkeypad,size,changed": this is called when virtualkeypad size is
+ * changed. @c event_info parameter is the virtualkeypad size in
+ * Evas_Coord_Rectangle structure. (@since 1.8)
  * @li "clipboard,state,on": if clipboard state is switched to "on".
  * (@since 1.8)
  * @li "clipboard,state,off": if clipboard state is switched to "off".

-- 

Re: [E-devel] [EGIT] [misc/entrance] master 01/01: entrance: many improvment * improve pam login * fix some profile mistake when login an user * use EINA_UNUSED * code refactoring * remove session log

[Stefan Schmidt]

Hello.

On 10/30/2013 03:51 AM, Daniel Juyung Seo wrote:
> On Wed, Oct 30, 2013 at 12:33 PM, Carsten Haitzler
> wrote:
>
>> On Wed, 30 Oct 2013 02:21:38 +0100 Michaël Bouchaud  said:
>>
>> i have to agree here. entrance still need to get to shipping/release
>> status, so
>> until then... work away at it to get it there. bureaucracy here is not
>> going to
>> help much or make people happy. let's wait until it's at that point
>>
>> yoz - btw. it's YOUR job to make some noise when *YOU* think entrance is
>> ready
>> to ship. :) so we know it's time to seriously bang at it. :)
>>
>>
> Hmm.. then why it's not in devs repository and bugging egit mailing list?

That is a fair question. If yoz considers entrance in a state that far 
away from a release so he can dump in stuff as he likes it should not be 
a top level project but live in his private dev space.

regards
Stefan Schmidt


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there *real* documentation for edje?

[Andrew F]

ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png  is working.


On Wed, Oct 30, 2013 at 3:30 AM, Carsten Haitzler wrote:

> On Tue, 29 Oct 2013 15:14:07 -0400 Robert Heller 
> said:
>
> > I am trying to write an alternitive version of the Enlightenment's 'start
> > menu', where instead of a cascade menu it is a three column thingy (I am
> not
> > sure what this sort of menu is called), something like this (from Mint):
> >
> > ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
>
> well that link doesn't work... no data. :)
>
> > But I am having a hard time figuring out how to do this.  The
> documentation
> > for edje leaves a lot to be desired and the API for enlightenment itself
> is
> > pretty much not documented at all.  I am a skilled C programmer, but
> without
> > useful documentation it is very hard to program...
>
> edje has a full reference. people have pointed to it already. there are
> intro
> docs all around. but like most things - the rest is "look at examples and
> build
> from there". i personally find documentation obtuse and wasteful compared
> to
> examples. you may perfer wandering through docs. i spent my early unix
> learning
> years reading every manual page i could find - but frankly, reading someone
> elses shell scripts and then just referring to a manual for reference was
> by
> far easier and more productive..
>
> now what i think your core problem here is, that you can't figure out how
> to do
> what you want.. because you literally can't do it in edje. you want to
> fundamentally change the behaviour and layout of a menu. not just
> re-shuffle
> some things, but change its core and that means you need to head off into
> the
> land of code. e_menu.c is where the entire menu code is. you wish to have
> similar functionality but different arrangement and that is a whole new
> kettle
> of fish. edje is merely a building-block to produce the gui elements you
> then
> lay out in code.
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 02/02: evas - gif loader rewrite (clean up code, document it a lot AND fix bugs)

[Rasterman]

raster pushed a commit to branch master.

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

commit 309e287b7c5ca4fb505d7756748d01da5c0fc203
Author: Carsten Haitzler (Rasterman) 
Date:   Wed Oct 30 18:16:09 2013 +0900

evas - gif loader rewrite (clean up code, document it a lot AND fix bugs)

after several days of beating head on desk, i gave up trying to find
the exact cause of some gifs not rendering right as animated gifs due
to the loader. it had something to do with dispose mode handling and
which frame it was applied to. i noticed the structure made it also
hard to fix, so this re-structures the entire thing with cleaner code,
less code AND more comments, with a limited memory cache (512k) for
previous frames per image (to avoid eating up huge memory blobs for
big/long animations - though at the expense of cpu), and with some
notes for future fixes - like fixing the "load 2 copies of the same
animated gif" issue... that's another day.

this does fix https://phab.enlightenment.org/T443 along with many
other things.
---
 src/modules/evas/loaders/gif/evas_image_load_gif.c | 1416 +---
 1 file changed, 602 insertions(+), 814 deletions(-)

diff --git a/src/modules/evas/loaders/gif/evas_image_load_gif.c 
b/src/modules/evas/loaders/gif/evas_image_load_gif.c
index 6c2c634..3f2ef53 100644
--- a/src/modules/evas/loaders/gif/evas_image_load_gif.c
+++ b/src/modules/evas/loaders/gif/evas_image_load_gif.c
@@ -8,315 +8,210 @@
 
 #include 
 
-#ifndef MIN
-# define MIN(a, b) (((a) < (b)) ? (a) : (b))
-#endif
-
-typedef struct _Gif_Frame Gif_Frame;
-
-typedef enum _Frame_Load_Type
-{
-   LOAD_FRAME_NONE = 0,
-   LOAD_FRAME_INFO = 1,
-   LOAD_FRAME_DATA = 2,
-   LOAD_FRAME_DATA_INFO = 3
-} Frame_Load_Type;
-
-struct _Gif_Frame
-{
-   struct {
-  /* Image descriptor */
-  intx;
-  inty;
-  intw;
-  inth;
-  intinterlace;
-   } image_des;
-
-   struct {
-  /* Graphic Control*/
-  intdisposal;
-  inttransparent;
-  intdelay;
-  intinput;
-   } frame_info;
-   int bg_val;
-};
+typedef struct _Frame_Info Frame_Info;
+typedef struct _Loader_Info Loader_Info;
 
-typedef struct _Evas_Loader_Internal Evas_Loader_Internal;
-struct _Evas_Loader_Internal
+struct _Loader_Info
 {
Eina_File *f;
Evas_Image_Load_Opts *opts;
Evas_Image_Animated *animated;
 };
 
-static Eina_Bool evas_image_load_specific_frame(Eina_File *f, const 
Evas_Image_Load_Opts *opts, Evas_Image_Property *prop, Evas_Image_Animated 
*animated, int frame_index, int *error);
+struct _Frame_Info
+{
+   int x, y, w, h;
+   unsigned short delay; // delay time in 1/100ths of a sec
+   short transparent : 10; // -1 == not, anything else == index 
+   short dispose : 6; // 0, 1, 2, 3 (others invalid)
+   short interlace : 1; // interlaced or not
+};
 
-#define byte2_to_int(a,b) (((b)<<8)|(a))
+#ifndef MIN
+# define MIN(a, b) (((a) < (b)) ? (a) : (b))
+#endif
+#define LOADERR(x) \
+do { \
+   *error = (x); \
+   goto on_error; \
+} while (0)
+#define PIX(_x, _y) rows[yin + _y][xin + _x]
+#define CMAP(_v) cmap->Colors[_v]
+#define PIXLK(_p) ARGB_JOIN(0xff, CMAP(_p).Red, CMAP(_p).Green, CMAP(_p).Blue)
 
-#define FRAME_MAX 1024
+// utility funcs...
 
-/* find specific frame in image entry */
-static Eina_Bool
-_find_frame(Evas_Image_Animated *animated, int frame_index, Image_Entry_Frame 
**frame)
+// brute force find frame index - gifs are normally saml so ok for now
+static Image_Entry_Frame *
+_find_frame(Evas_Image_Animated *animated, int index)
 {
Eina_List *l;
-   Image_Entry_Frame *hit_frame = NULL;
+   Image_Entry_Frame *frame;
 
-   if (!animated->frames) return EINA_FALSE;
-
-   EINA_LIST_FOREACH(animated->frames, l, hit_frame)
+   if (!animated->frames) return NULL;
+   EINA_LIST_FOREACH(animated->frames, l, frame)
  {
-if (hit_frame->index == frame_index)
-  {
- *frame = hit_frame;
- return EINA_TRUE;
-  }
+if (frame->index == index) return frame;
  }
-   return EINA_FALSE;
+   return NULL;
 }
 
-static Eina_Bool
-_find_close_frame(Evas_Image_Animated *animated, int frame_index, 
Image_Entry_Frame **frame)
-{
-  Eina_Bool hit = EINA_FALSE;
-  int i;
-
-  i = frame_index -1;
-
-  if (!animated->frames) return EINA_FALSE;
-
-  for (; i > 0; i--)
-{
-   hit = _find_frame(animated, i, frame);
-   if (hit)
- return  EINA_TRUE;
-}
-  return EINA_FALSE;
-}
-
-static Eina_Bool
-_evas_image_skip_frame(GifFileType *gif, int frame)
+// fill in am image with a specific rgba color value
+static void
+_fill_image(DATA32 *data, int rowpix, DATA32 val, int x, int y, int w, int h)
 {
-   int remain_frame = 0;
-   GifRecordType   rec;
-
-   if (!gif) return EINA_FALSE;
-   if (frame == 0) return EINA_TRUE; /* no need to ski

[EGIT] [core/efl] master 01/02: evas - animated images. fix leak in not freeing the list of frames itself

[Rasterman]

raster pushed a commit to branch master.

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

commit 6c28aff7a0ac5c917d03f9f275ce3aa0dd749d1c
Author: Carsten Haitzler (Rasterman) 
Date:   Wed Oct 30 18:08:10 2013 +0900

evas - animated images. fix leak in not freeing the list of frames itself
---
 src/lib/evas/common/evas_image_main.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/src/lib/evas/common/evas_image_main.c 
b/src/lib/evas/common/evas_image_main.c
index b9d64ce..1492d80 100644
--- a/src/lib/evas/common/evas_image_main.c
+++ b/src/lib/evas/common/evas_image_main.c
@@ -291,16 +291,13 @@ _evas_common_rgba_image_delete(Image_Entry *ie)
 
if (ie->animated.frames)
  {
-Eina_List *l;
 Image_Entry_Frame *frame;
-EINA_LIST_FOREACH(ie->animated.frames, l, frame)
+
+EINA_LIST_FREE(ie->animated.frames, frame)
   {
-   if (frame)
- {
-if (frame->data) free(frame->data);
-if (frame->info) free(frame->info);
-free (frame);
- }
+ if (frame->data) free(frame->data);
+ if (frame->info) free(frame->info);
+ free(frame);
   }
  }
if (ie->f && !ie->flags.given_mmap) eina_file_close(ie->f);

-- 

[EGIT] [bindings/python/python-efl] master 01/03: utils.logger: PyUnicode_FromFormatV -> vsprintf

[Kai Huuhko]

kuuko pushed a commit to branch master.

http://git.enlightenment.org/bindings/python/python-efl.git/commit/?id=f9971fecc57561fab37c6385aa611c1153157bc4

commit f9971fecc57561fab37c6385aa611c1153157bc4
Author: Kai Huuhko 
Date:   Wed Oct 30 11:26:14 2013 +0200

utils.logger: PyUnicode_FromFormatV -> vsprintf

The Py function segfaults with certain (malformed?) messages.
---
 efl/utils/logger.pyx | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/efl/utils/logger.pyx b/efl/utils/logger.pyx
index 2866a51..22ce861 100644
--- a/efl/utils/logger.pyx
+++ b/efl/utils/logger.pyx
@@ -19,7 +19,8 @@ from libc.string cimport const_char
 from efl.eina cimport Eina_Log_Domain, const_Eina_Log_Domain, Eina_Log_Level, \
 eina_log_print_cb_set, eina_log_domain_register, eina_log_level_set, \
 eina_log_level_get, eina_log_domain_level_get, eina_log_domain_level_set, \
-eina_log_print
+eina_log_print, EINA_LOG_DOM_DBG, EINA_LOG_DOM_INFO, EINA_LOG_DOM_WARN, \
+EINA_LOG_DOM_ERR, EINA_LOG_DOM_CRIT
 from cpython cimport PyUnicode_AsUTF8String, PY_VERSION_HEX
 
 import logging
@@ -29,8 +30,8 @@ cdef extern from "stdarg.h":
 ctypedef struct va_list:
 pass
 
-cdef extern from "Python.h":
-object PyUnicode_FromFormatV(char *format, va_list vargs)
+cdef extern from "stdio.h":
+int vsprintf(char *, const_char *fmt, va_list args)
 
 cdef tuple log_levels = (
 50,
@@ -46,8 +47,14 @@ cdef void py_eina_log_print_cb(const_Eina_Log_Domain *d,
   Eina_Log_Level level,
   const_char *file, const_char *fnc, int line,
   const_char *fmt, void *data, va_list args) with 
gil:
-cdef unicode msg = PyUnicode_FromFormatV(fmt, args)
-cdef unicode name = d.name.decode("utf-8")
+cdef:
+char tmp[256]
+cdef unicode msg
+cdef unicode name = d.name.decode("utf-8")
+
+vsprintf(tmp, fmt, args)
+msg = tmp.decode("utf-8")
+
 rec = logging.LogRecord(name, log_levels[level], file, line, msg, None, 
None, fnc)
 logger = loggers.get(name, loggers["efl"])
 logger.handle(rec)
@@ -103,3 +110,6 @@ rootlog = add_logger("efl")
 rootlog.propagate = False
 
 cdef public int PY_EFL_LOG_DOMAIN = rootlog.eina_log_domain
+
+def logger_test_dbg():
+EINA_LOG_DOM_DBG(PY_EFL_LOG_DOMAIN, "test message", NULL)

-- 

[EGIT] [bindings/python/python-efl] master 03/03: Elementary: More work on the examples.

[Kai Huuhko]

kuuko pushed a commit to branch master.

http://git.enlightenment.org/bindings/python/python-efl.git/commit/?id=39598ed1f7283eb88b2040b26ab1263c6a47bb5c

commit 39598ed1f7283eb88b2040b26ab1263c6a47bb5c
Author: Kai Huuhko 
Date:   Wed Oct 30 11:36:54 2013 +0200

Elementary: More work on the examples.
---
 examples/elementary/test_3d.py |   7 +-
 examples/elementary/test_access.py |   8 +-
 examples/elementary/test_bg.py |  14 ++-
 examples/elementary/test_box.py|  11 ++-
 examples/elementary/test_bubble.py | 101 +++--
 examples/elementary/test_button.py |  56 +---
 examples/elementary/test_calendar.py   |  45 -
 examples/elementary/test_check.py  |  81 +++--
 examples/elementary/test_clock.py  |  45 +++--
 examples/elementary/test_cnp.py|  52 +--
 examples/elementary/test_colorselector.py  |  95 +--
 .../elementary/test_core_evas_canvas_callbacks.py  |   6 ++
 12 files changed, 217 insertions(+), 304 deletions(-)

diff --git a/examples/elementary/test_3d.py b/examples/elementary/test_3d.py
index 502dd8b..c7838e7 100644
--- a/examples/elementary/test_3d.py
+++ b/examples/elementary/test_3d.py
@@ -1,6 +1,8 @@
 #!/usr/bin/env python
 # encoding: utf-8
 
+import os
+
 from efl.evas import EVAS_HINT_EXPAND, EVAS_HINT_FILL, Image, Map
 from efl import elementary
 from efl.elementary.window import StandardWindow
@@ -11,6 +13,9 @@ EXPAND_BOTH = EVAS_HINT_EXPAND, EVAS_HINT_EXPAND
 FILL_BOTH = EVAS_HINT_FILL, EVAS_HINT_FILL
 FILL_HORIZ = EVAS_HINT_FILL, 0.5
 
+img_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), "images")
+ic_file = os.path.join(img_path, "rock_02.jpg")
+
 class Point(object):
 def __init__(self, x, y, z, u, v):
 self.x = x
@@ -26,7 +31,7 @@ class Side(object):
 self.points = []
 
 img = Image(eva)
-img.file = "images/rock_02.jpg",
+img.file = ic_file
 img.fill = (0, 0, 256, 256)
 img.smooth_scale = False
 img.resize(256, 256)
diff --git a/examples/elementary/test_access.py 
b/examples/elementary/test_access.py
index 9bf6718..54c8143 100644
--- a/examples/elementary/test_access.py
+++ b/examples/elementary/test_access.py
@@ -1,6 +1,8 @@
 #!/usr/bin/env python
 # encoding: utf-8
 
+import os
+
 from efl.evas import EVAS_HINT_FILL, EVAS_HINT_EXPAND, \
 EVAS_ASPECT_CONTROL_VERTICAL
 from efl import elementary
@@ -22,6 +24,7 @@ FILL_BOTH = EVAS_HINT_FILL, EVAS_HINT_FILL
 
 config = Configuration()
 
+img_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), "images")
 
 def cleanup_cb(obj):
 config.access = False
@@ -36,7 +39,7 @@ class GLItC1(GenlistItemClass):
 size_hint_align=FILL_BOTH, size_hint_weight=EXPAND_BOTH,
 )
 else:
-bt = Icon(gl, file="images/logo_small.png",
+bt = Icon(gl, file=os.path.join(img_path, "logo_small.png")
 size_hint_aspect=(EVAS_ASPECT_CONTROL_VERTICAL, 1, 1)
 )
 
@@ -68,7 +71,8 @@ class GLItC2(GenlistItemClass):
 class GGItC(GengridItemClass):
 def content_get(self, gg, part, data):
 if not part == "elm.swallow.icon":
-ic = Icon(gg, scale=0.5, file="images/icon_%02i.png" % (data % 4),
+ic = Icon(gg, scale=0.5,
+file=os.path.join(img_path, "icon_%02i.png" % (data % 4)),
 resizable=(0, 0),
 size_hint_weight=EXPAND_BOTH, size_hint_align=(0.5, 0.5)
 )
diff --git a/examples/elementary/test_bg.py b/examples/elementary/test_bg.py
index 7e22053..00242eb 100644
--- a/examples/elementary/test_bg.py
+++ b/examples/elementary/test_bg.py
@@ -14,6 +14,9 @@ from efl.elementary.list import List
 EXPAND_BOTH = EVAS_HINT_EXPAND, EVAS_HINT_EXPAND
 FILL_BOTH = EVAS_HINT_FILL, EVAS_HINT_FILL
 
+img_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), "images")
+ic_file = os.path.join(img_path, "plant_01.jpg")
+
 def bg_plain_clicked(obj, item=None):
 win = Window("bg plain", ELM_WIN_BASIC, title="Bg Plain", autodel=True,
 size=(320, 320)
@@ -31,7 +34,7 @@ def bg_image_clicked(obj, item=None):
 size=(320, 320), size_hint_min=(160, 160), size_hint_max=(320,320)
 )
 
-bg = Background(win, file="images/plant_01.jpg", 
option=ELM_BG_OPTION_SCALE,
+bg = Background(win, file=ic_file, option=ELM_BG_OPTION_SCALE,
 size_hint_weight=EXPAND_BOTH
 )
 win.resize_object_add(bg)
@@ -45,14 +48,9 @@ def bg_image_clicked(obj, item=None):
 
 
 if __name__ == "__main__":
-def destroy(obj):
-elementary.exit()
-
 elementary.init()
-win = StandardWindow("test", "python-elementary test application",
-size=(320,520)
-)
-win.callback_delete_request_add(destroy)
+win = Sta

[EGIT] [bindings/python/python-efl] master 02/03: Elementary.mbe: Remove commented out code, comment out an unimplemented method.

[Kai Huuhko]

kuuko pushed a commit to branch master.

http://git.enlightenment.org/bindings/python/python-efl.git/commit/?id=fd8159d4ec9f8bce43c777dda8095353accb6fb9

commit fd8159d4ec9f8bce43c777dda8095353accb6fb9
Author: Kai Huuhko 
Date:   Wed Oct 30 11:30:35 2013 +0200

Elementary.mbe: Remove commented out code, comment out an unimplemented 
method.
---
 efl/elementary/multibuttonentry.pyx | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/efl/elementary/multibuttonentry.pyx 
b/efl/elementary/multibuttonentry.pyx
index 33df0c0..f5c2ecb 100644
--- a/efl/elementary/multibuttonentry.pyx
+++ b/efl/elementary/multibuttonentry.pyx
@@ -68,8 +68,6 @@ from efl.evas cimport Object as evasObject
 
 from libc.stdlib cimport free
 from libc.string cimport strdup
-from efl.eina cimport Eina_Stringshare, eina_stringshare_add, 
eina_stringshare_del, \
-eina_stringshare_replace
 from object cimport Object
 import traceback
 from object_item cimport_object_item_callback, \
@@ -78,6 +76,7 @@ from object_item cimport_object_item_callback, \
 
 cdef Eina_Bool _multibuttonentry_filter_callback(Evas_Object *obj, \
 const_char *item_label, void *item_data, void *data) with gil:
+
 cdef:
 MultiButtonEntry mbe = object_from_instance(obj)
 bint ret
@@ -91,18 +90,6 @@ cdef Eina_Bool _multibuttonentry_filter_callback(Evas_Object 
*obj, \
 
 return ret
 
-# XXX: MBE API is teh b0rg
-# if ret is None:
-# eina_stringshare_del(item_label)
-# item_label = NULL
-# return 1
-# elif isinstance(ret, (str, unicode)):
-# ret = PyUnicode_AsUTF8String(ret)
-# item_label = eina_stringshare_replace(&item_label, strdup(ret))
-# return 1
-# else:
-# return 0
-
 cdef class MultiButtonEntryItem(ObjectItem):
 
 """An item for the MultiButtonEntry widget."""
@@ -331,9 +318,9 @@ cdef class MultiButtonEntry(Object):
 
 Py_INCREF(cbdata)
 
-def filter_remove(self, func, *args, **kwargs):
-#TODO
-pass
+#TODO
+#def filter_remove(self, func, *args, **kwargs):
+#pass
 
 property editable:
 """Whether the multibuttonentry is to be editable or not.

-- 

Re: [E-devel] Is there *real* documentation for edje?

[The Rasterman]

On Wed, 30 Oct 2013 09:07:29 + Andrew F  said:

> ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png  is working.

not here - not when i have to go via a squid proxy...

Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without
sending any data.

but i guessed on what he wanted to do anyway... ie the windows start menu with
its multiple columns of varying info... :)

> On Wed, Oct 30, 2013 at 3:30 AM, Carsten Haitzler wrote:
> 
> > On Tue, 29 Oct 2013 15:14:07 -0400 Robert Heller 
> > said:
> >
> > > I am trying to write an alternitive version of the Enlightenment's 'start
> > > menu', where instead of a cascade menu it is a three column thingy (I am
> > not
> > > sure what this sort of menu is called), something like this (from Mint):
> > >
> > > ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
> >
> > well that link doesn't work... no data. :)
> >
> > > But I am having a hard time figuring out how to do this.  The
> > documentation
> > > for edje leaves a lot to be desired and the API for enlightenment itself
> > is
> > > pretty much not documented at all.  I am a skilled C programmer, but
> > without
> > > useful documentation it is very hard to program...
> >
> > edje has a full reference. people have pointed to it already. there are
> > intro
> > docs all around. but like most things - the rest is "look at examples and
> > build
> > from there". i personally find documentation obtuse and wasteful compared
> > to
> > examples. you may perfer wandering through docs. i spent my early unix
> > learning
> > years reading every manual page i could find - but frankly, reading someone
> > elses shell scripts and then just referring to a manual for reference was
> > by
> > far easier and more productive..
> >
> > now what i think your core problem here is, that you can't figure out how
> > to do
> > what you want.. because you literally can't do it in edje. you want to
> > fundamentally change the behaviour and layout of a menu. not just
> > re-shuffle
> > some things, but change its core and that means you need to head off into
> > the
> > land of code. e_menu.c is where the entire menu code is. you wish to have
> > similar functionality but different arrangement and that is a whole new
> > kettle
> > of fish. edje is merely a building-block to produce the gui elements you
> > then
> > lay out in code.
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> >
> > --
> > Android is increasing in popularity, but the open development platform that
> > developers love is also attractive to malware creators. Download this white
> > paper to learn more about secure code signing practices that can help keep
> > Android apps secure.
> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/elementary] master 01/01: elm_slider: Step set/get API additions.

[Daniel Juyung Seo]

seoz pushed a commit to branch master.

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

commit c7c245da67038ae70d66b8091346a0b8503659ce
Author: Daniel Juyung Seo 
Date:   Wed Oct 30 18:56:29 2013 +0900

elm_slider: Step set/get API additions.

Issue: As step size was hard coded in the widget, when slider indicator is 
dragged

using a key event or during accessibility the value was not exactly 
incremented/decremented

instead same value was shown more than1 time/values were skipped.

Solution: Two APIs added which will set/get step size.

Reviewer: SeoZ
Reviewer Comment: This is a manual merge of D293 due to arc issue on Shilpa.
I modified some codes from her original code. She'll use arc next time.
 fixed documentation
 fixed typos.
 fixed indentation
 used macro
 added some guide codes.
 removed unnecessary empty line.
 updated NEWS and ChangeLog.
---
 ChangeLog   |  4 
 NEWS|  1 +
 src/bin/test_slider.c   | 25 
 src/lib/elm_slider.c| 47 +++--
 src/lib/elm_slider_eo.h | 37 +++
 src/lib/elm_slider_legacy.h | 29 
 src/lib/elm_widget_slider.h |  2 +-
 7 files changed, 142 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e99d3fd..0060f0a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1731,3 +1731,7 @@
 2013-10-30  Daniel Juyung Seo (SeoZ)
 
 * conform: Added "virtualkeypad,size,changed" callback on 
virtualkeypad min size change.
+
+2013-10-30  Shilpa Onkar Singh
+
+* slider: Added elm_slider_step_get(), elm_slider_step_set().
diff --git a/NEWS b/NEWS
index 6876073..3d59bc7 100644
--- a/NEWS
+++ b/NEWS
@@ -102,6 +102,7 @@ Additions:
* Add signals "spinner,drag,start" and "spinner,drag,stop" to the spinner 
widget.
* Add support for "clicked" callback on Return/space/KP_Enter key press for 
image.
* Add "virtualkeypad,size,changed" callback on virtualkeypad min size 
change for conformant.
+   * Add elm_slider_step_get(), elm_slider_step_set() for slider.
 
 Improvements:
 
diff --git a/src/bin/test_slider.c b/src/bin/test_slider.c
index 8d85ce7..a4b1398 100644
--- a/src/bin/test_slider.c
+++ b/src/bin/test_slider.c
@@ -48,10 +48,22 @@ _bt_m1(void *data, Evas_Object *obj EINA_UNUSED, void 
*event_info EINA_UNUSED)
elm_slider_value_set(data, elm_slider_value_get(data) - 0.1);
 }
 
+static double
+_step_size_calculate(double min, double max)
+{
+   double step = 0.0;
+   int steps = 0;
+
+   steps = max - min;
+   if (steps) step = (1.0 / steps);
+   return step;
+}
+
 void
 test_slider(void *data EINA_UNUSED, Evas_Object *obj EINA_UNUSED, void 
*event_info EINA_UNUSED)
 {
Evas_Object *win, *fr, *bx, *sl, *ic, *sl1, *bx2, *bt;
+   double step;
char buf[PATH_MAX];
 
win = elm_win_util_standard_add("slider", "Slider");
@@ -88,6 +100,19 @@ test_slider(void *data EINA_UNUSED, Evas_Object *obj 
EINA_UNUSED, void *event_in
elm_box_pack_end(bx, sl);
evas_object_show(sl);
 
+   sl = elm_slider_add(bx);
+   elm_slider_unit_format_set(sl, "%1.0f units");
+   elm_slider_indicator_format_set(sl, "%1.0f");
+   elm_slider_span_size_set(sl, 120);
+   elm_slider_min_max_set(sl, 0, 9);
+   elm_object_text_set(sl, "Manual step");
+   step = _step_size_calculate(0, 9);
+   elm_slider_step_set(sl, step);
+   evas_object_size_hint_align_set(sl, EVAS_HINT_FILL, 0.5);
+   evas_object_size_hint_weight_set(sl, EVAS_HINT_EXPAND, 0.0);
+   elm_box_pack_end(bx, sl);
+   evas_object_show(sl);
+
// normal horizontal slider
ic = elm_icon_add(bx);
snprintf(buf, sizeof(buf), "%s/images/logo_small.png", 
elm_app_data_dir_get());
diff --git a/src/lib/elm_slider.c b/src/lib/elm_slider.c
index 22a81af..0e3fb53 100755
--- a/src/lib/elm_slider.c
+++ b/src/lib/elm_slider.c
@@ -14,6 +14,7 @@ EAPI Eo_Op ELM_OBJ_SLIDER_BASE_ID = EO_NOOP;
 
 #define MY_CLASS_NAME "elm_slider"
 #define SLIDER_DELAY_CHANGED_INTERVAL 0.2
+#define SLIDER_STEP 0.05
 
 static const Elm_Layout_Part_Alias_Description _content_aliases[] =
 {
@@ -260,7 +261,7 @@ _drag_up(void *data,
double step;
 
ELM_SLIDER_DATA_GET(data, sd);
-   step = 0.05;
+   step = sd->step;
 
if (sd->inverted) step *= -1.0;
 
@@ -278,7 +279,7 @@ _drag_down(void *data,
double step;
 
ELM_SLIDER_DATA_GET(data, sd);
-   step = -0.05;
+   step = -sd->step;
 
if (sd->inverted) step *= -1.0;
 
@@ -821,6 +822,7 @@ _elm_slider_smart_add(Eo *obj, void *_pd, va_list *list 
EINA_UNUSED)
priv->horizontal = EINA_TRUE;
priv->indicator_show = EINA_TRUE;
priv->val_max = 1.0;
+   priv->step = SLIDER_STEP;
 
if (!elm_layout_theme_set
(obj, "slider", "horizontal", elm_widget_style_get(obj)))
@@ -1343,6 +1345,43 @@ _elm_slider_indicator_show_get(Eo *obj EINA_UNUSED, void 
*_pd, va_lis

[EGIT] [core/elementary] master 01/01: compliance/licensing - clarify, fix formatting and point to tldrlegal.com

[Rasterman]

raster pushed a commit to branch master.

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

commit c6a09bf72778d48d0d93e92ef58f73e77c913291
Author: Carsten Haitzler (Rasterman) 
Date:   Wed Oct 30 19:28:16 2013 +0900

compliance/licensing - clarify, fix formatting and point to tldrlegal.com
---
 COMPLIANCE | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/COMPLIANCE b/COMPLIANCE
index 0b6593a..1d98aee 100644
--- a/COMPLIANCE
+++ b/COMPLIANCE
@@ -29,18 +29,19 @@ F.A.Q.
 
 Q. Where is the licensing information?
 A. See the COPYING file here in this directory. This is the proper legal
-information you will need.
+information you will need. It covers all of elementary, EXCEPT the
+theme which is public domain (the text files only - images are not).
 
 Q. Do I need to make the source public of libraries or applications that I
 build on top of Elementary?
-A. No. Even the default theme is public domain, whihc means you can
+A. No. Even the default theme is public domain, which means you can
 make your own by copying it and starting from there, and you may
 license your copied variation any way you like.
 
 Q. Do I need to provide the source for Elementary?
 A. Yes. In general you do. If you are shipping any of the binaries or
-libraries that are produced, you must provide the EXACT source code
-used to build those binaries. So stick to doing this and you'll be fine.
+libraries built from Elementary, you must provide the EXACT source code
+used to build those binaries.
 
 Q. If I have to provide source, how should I do this?
 A. The best way is to provide a reference in an "about" dialog in the
@@ -65,3 +66,8 @@ source code, provide them as part of the user interface in 
full (e.g.
 in a dialog), or as files in the filesystem, on actual printed
 material (manuals, papers) that accompany the product or in CD, DVD
 etc. media.
+
+Q. Is there a simpler list of do's and don'ts i can use?
+A. Yes. See http://www.tldrlegal.com. specifically:
+
+http://www.tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)

-- 

[EGIT] [core/efl] master 01/01: compliance/licensing - clarify, fix formatting and point to tldrlegal.com

[Rasterman]

raster pushed a commit to branch master.

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

commit b3debcc3e1651e41c419db422b465d9070c180b4
Author: Carsten Haitzler (Rasterman) 
Date:   Wed Oct 30 19:27:26 2013 +0900

compliance/licensing - clarify, fix formatting and point to tldrlegal.com
---
 COMPLIANCE | 24 ++--
 COPYING|  2 +-
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/COMPLIANCE b/COMPLIANCE
index 1ee0023..ecd0c34 100644
--- a/COMPLIANCE
+++ b/COMPLIANCE
@@ -16,14 +16,16 @@ The simple advice
 files as printed material with your product and/or in a dialog (e.g.
 an "about" dialog) in your product user interface.
 2. Provide a URL from which to be able to download "tar files" with
-ALL of the source of EFL exactly as it was when used to compile the
-binaries for your product that ships EFL. Keep this URL valid for the
-lifetime of the product.
+ALL of the source of this software exactly as it was when used to compile the
+binaries for your product. Keep this URL valid for the lifetime of the product.
 3. Unless you are doing PS3 (PSl1ght) development any libraries or
 applications you write that use EFL are yours and you do not need to
-make the source available.
+make the source available. That means if you link to EFL dynamically.
+If you copy in EFL source into your application or library or
+statically link, then you will need to provide full source of whatever
+statically links or copies any of this software into yours.
 4. If you made changes to EFL it would be appreciated if you
-interacted with us (see http://www.enlightenment.org ) and provided the
+interacted with us (see http://www.enlightenment.org) and provided the
 changes you made in patch form BEFORE you ship a product, so they may
 be reviewed to see if you have made any mistakes and perhaps have
 created problems you do not know of yet.
@@ -44,7 +46,7 @@ relevant.
 Q. Do I need to provide the source for EFL?
 A. Yes. In general you do. If you are shipping any of the binaries or
 libraries that are produced, you must provide the EXACT source code
-used to build those binaries. So stick to doing this and you'll be fine.
+used to build those binaries.
 
 Q. If I have to provide source, how should I do this?
 A. The best way is to provide a reference in an "about" dialog in the
@@ -69,3 +71,13 @@ source code, provide them as part of the user interface in 
full (e.g.
 in a dialog), or as files in the filesystem, on actual printed
 material (manuals, papers) that accompany the product or in CD, DVD
 etc. media.
+
+Q. Is there a simpler list of do's and don'ts i can use?
+A. Yes. See http://www.tldrlegal.com. specifically:
+
+http://www.tldrlegal.com/license/bsd-2-clause-license-(freebsd)
+http://www.tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)
+http://www.tldrlegal.com/license/gnu-general-public-license-v2-(gpl-2)
+http://www.tldrlegal.com/license/zlib-libpng-license-(zlib)
+
+Then match this up with the licensing listed in COPYING.
diff --git a/COPYING b/COPYING
index 3aa431f..80f87c3 100644
--- a/COPYING
+++ b/COPYING
@@ -20,7 +20,7 @@ evas:licenses/COPYING.BSD
 embryo:  licenses/COPYING.SMALL
 ecore:   licenses/COPYING.BSD
 eio: licenses/COPYING.LGPL
-eldbus:   licenses/COPYING.LGPL
+eldbus:  licenses/COPYING.LGPL
 efreet:  licenses/COPYING.BSD
 eeze:licenses/COPYING.BSD
 ephysics:licenses/COPYING.BSD

-- 

Re: [E-devel] [EGIT] [core/efl] master 01/03: Stop leaking evas objects in Lua.

[Leif Middelschulte]

Unfortunately, this bug is still valid.
Applications using lua crash, if it creates(/deletes) sufficient elements.
See https://phab.enlightenment.org/T323 for an example that will crash
e.g. edje_player if the window is resized a couple of times.

Could you have another look? I guess that increasing the number of
rects should crash the applications right on startup.

Regards,

Leif

2013/5/22 David Walter Seikel - Enlightenment Git :
> onefang pushed a commit to branch master.
>
> commit d6b3e8848a6aaa132e4211c4a6bf2e764a74bcc6
> Author: David Walter Seikel 
> Date:   Wed May 22 12:55:41 2013 +1000
>
> Stop leaking evas objects in Lua.
>
> Bug and test case reported by Leif Middelschulte.
> ---
>  src/lib/edje/edje_lua2.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/lib/edje/edje_lua2.c b/src/lib/edje/edje_lua2.c
> index ec5d48a..8bb7f02 100644
> --- a/src/lib/edje/edje_lua2.c
> +++ b/src/lib/edje/edje_lua2.c
> @@ -327,9 +327,13 @@ _elua_obj_new(lua_State *L, Edje *ed, int size, const 
> char *metatable)  // Stack
>  }
>
>  static void
> -_elua_obj_free(lua_State *L EINA_UNUSED, Edje_Lua_Obj *obj)
> +_elua_obj_free(lua_State *L, Edje_Lua_Obj *obj)
>  {
> if (!obj->free_func) return;
> +   // Free the reference, so it will actually get gc'd.
> +   // It seems that being a completely weak table isn't enough.
> +   lua_pushnil(L);  // Stack usage [-0, +1, 
> -]
> +   _elua_ref_set(L, obj);   // Stack usage [-4, +4, 
> m]
> obj->free_func(obj);
> obj->ed->lua_objs = eina_inlist_remove(obj->ed->lua_objs, 
> EINA_INLIST_GET(obj));
> obj->free_func = NULL;
> @@ -3888,7 +3892,7 @@ _elua_init(void)
> lua_pushlightuserdata(L, &_elua_objs);
>   // Stack usage [-0, +1, -]
> lua_newtable(L);  
>   // Stack usage [-0, +1, m]
> lua_pushstring(L, "__mode");  
>   // Stack usage [-0, +1, m]
> -   lua_pushstring(L, "v");   
>   // Stack usage [-0, +1, m]
> +   lua_pushstring(L, "kv");  
>   // Stack usage [-0, +1, m]
> lua_rawset(L, -3);
>   // Stack usage [-2, +0, m]
> lua_rawset(L, LUA_REGISTRYINDEX); 
>   // Stack usage [-2, +0, m]
>  }
> @@ -3978,7 +3982,7 @@ _edje_lua2_script_init(Edje *ed)
>   // Stack usage
> lua_pushlightuserdata(L, &_elua_objs); // Stack 
> usage [-0, +1, -]
> lua_newtable(L);   // Stack 
> usage [-0, +1, m]
> lua_pushstring(L, "__mode");   // Stack 
> usage [-0, +1, m]
> -   lua_pushstring(L, "v");// Stack 
> usage [-0, +1, m]
> +   lua_pushstring(L, "kv");   // Stack 
> usage [-0, +1, m]
> lua_rawset(L, -3); // Stack 
> usage [-2, +0, m]
> lua_rawset(L, LUA_REGISTRYINDEX);  // Stack 
> usage [-2, +0, m]
>
>
> --
>
> --
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 03/04: evas/cserve2: Prevent potential infinite loop (shutdown)

[Jean-Philippe Andre]

jpeg pushed a commit to branch master.

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

commit 498418bb67c1642d5ccdaa71b393eb57060f1d32
Author: Jean-Philippe Andre 
Date:   Wed Oct 30 14:57:52 2013 +0900

evas/cserve2: Prevent potential infinite loop (shutdown)

In shutdown, I've encountered an infinite loop.
It SHOULD NOT possibly happen, but somehow some image
was marked as delete_me=1 but still present in the LRU.
---
 src/lib/evas/cache2/evas_cache2.c | 23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/src/lib/evas/cache2/evas_cache2.c 
b/src/lib/evas/cache2/evas_cache2.c
index 5ec5b6d..921d04a 100644
--- a/src/lib/evas/cache2/evas_cache2.c
+++ b/src/lib/evas/cache2/evas_cache2.c
@@ -523,26 +523,19 @@ evas_cache2_shutdown(Evas_Cache2 *cache)
 {
Eina_List *delete_list;
Image_Entry *im;
+   Eina_Inlist *il;
+
+   EINA_INLIST_FOREACH_SAFE(cache->lru, il, im)
+ _evas_cache2_image_entry_delete(cache, im);
 
-   while (cache->lru)
- {
-im = (Image_Entry *)cache->lru;
-_evas_cache2_image_entry_delete(cache, im);
- }
/* This is mad, I am about to destroy image still alive, but we need to 
prevent leak. */
-   while (cache->dirty)
- {
-im = (Image_Entry *)cache->dirty;
-_evas_cache2_image_entry_delete(cache, im);
- }
+   EINA_INLIST_FOREACH_SAFE(cache->dirty, il, im)
+ _evas_cache2_image_entry_delete(cache, im);
 
delete_list = NULL;
eina_hash_foreach(cache->activ, _evas_cache2_image_free_cb, &delete_list);
-   while (delete_list)
- {
-_evas_cache2_image_entry_delete(cache, 
eina_list_data_get(delete_list));
-delete_list = eina_list_remove_list(delete_list, delete_list);
- }
+   EINA_LIST_FREE(delete_list, im)
+ _evas_cache2_image_entry_delete(cache, im);
 
eina_hash_free(cache->activ);
eina_hash_free(cache->inactiv);

-- 

[EGIT] [core/efl] master 04/04: evas/cserve2: Prevent another infinite loop (flush)

[Jean-Philippe Andre]

jpeg pushed a commit to branch master.

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

commit b3b5999847a4597fbc8c127970a669d17b0b57de
Author: Jean-Philippe Andre 
Date:   Wed Oct 30 15:16:21 2013 +0900

evas/cserve2: Prevent another infinite loop (flush)

And add some error messages
---
 src/lib/evas/cache2/evas_cache2.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/src/lib/evas/cache2/evas_cache2.c 
b/src/lib/evas/cache2/evas_cache2.c
index 921d04a..3e0fad6 100644
--- a/src/lib/evas/cache2/evas_cache2.c
+++ b/src/lib/evas/cache2/evas_cache2.c
@@ -528,10 +528,18 @@ evas_cache2_shutdown(Evas_Cache2 *cache)
EINA_INLIST_FOREACH_SAFE(cache->lru, il, im)
  _evas_cache2_image_entry_delete(cache, im);
 
+   if (cache->lru)
+ ERR("Cache2 LRU still contains %d elements after dump!",
+ eina_inlist_count(cache->lru));
+
/* This is mad, I am about to destroy image still alive, but we need to 
prevent leak. */
EINA_INLIST_FOREACH_SAFE(cache->dirty, il, im)
  _evas_cache2_image_entry_delete(cache, im);
 
+   if (cache->dirty)
+ ERR("Cache2 dirty pool still contains %d elements after dump!",
+ eina_inlist_count(cache->dirty));
+
delete_list = NULL;
eina_hash_foreach(cache->activ, _evas_cache2_image_free_cb, &delete_list);
EINA_LIST_FREE(delete_list, im)
@@ -540,6 +548,9 @@ evas_cache2_shutdown(Evas_Cache2 *cache)
eina_hash_free(cache->activ);
eina_hash_free(cache->inactiv);
 
+   if (cache->usage > 0)
+ WRN("Cache2 reports %d bytes used after shutdown.", cache->usage);
+
free(cache);
 }
 
@@ -1128,14 +1139,20 @@ on_error:
 EAPI int
 evas_cache2_flush(Evas_Cache2 *cache)
 {
+   Eina_Inlist *cur, *prev;
+
if (cache->limit == -1) return -1;
+   if (!cache->lru) return cache->usage; // Should be 0
 
-   while ((cache->lru) && (cache->limit < cache->usage))
+   //EINA_INLIST_FOREACH_REVERSE_SAFE(cache->lru, cur, prev, im)
+   for (cur = cache->lru->last;
+cur && (cache->limit < cache->usage);
+cur = prev)
  {
 Image_Entry *im;
 
-im = (Image_Entry *)cache->lru->last;
-DBG("Remove unused entry from cache.");
+prev = cur->prev;
+im = EINA_INLIST_CONTAINER_GET(cur, Image_Entry);
 _evas_cache2_image_entry_delete(cache, im);
  }
 

-- 

[EGIT] [core/efl] master 01/04: evas/cserve2: Fix image preload with gl-x11 engine

[Jean-Philippe Andre]

jpeg pushed a commit to branch master.

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

commit 82e8028b5d34ccf488eb3faed30f67b4b40bfaed
Author: Jean-Philippe Andre 
Date:   Tue Oct 29 19:06:33 2013 +0900

evas/cserve2: Fix image preload with gl-x11 engine

Cserves supports only the SW (xlib) and GL (gl-x11) engines.
Also, improve cs2 support for some lesser used functions in the
gl_x11 engine.
---
 src/lib/evas/cache2/evas_cache2.c  |  1 +
 src/lib/evas/cache2/evas_cache2.h  |  1 +
 src/modules/evas/engines/gl_common/evas_gl_image.c |  6 +++
 .../evas/engines/gl_common/evas_gl_preload.c   | 19 ++
 .../evas/engines/gl_common/evas_gl_texture.c   | 10 +
 src/modules/evas/engines/gl_x11/evas_engine.c  | 43 +++---
 .../evas/engines/software_generic/evas_engine.c|  9 -
 7 files changed, 82 insertions(+), 7 deletions(-)

diff --git a/src/lib/evas/cache2/evas_cache2.c 
b/src/lib/evas/cache2/evas_cache2.c
index d4b2b53..5ec5b6d 100644
--- a/src/lib/evas/cache2/evas_cache2.c
+++ b/src/lib/evas/cache2/evas_cache2.c
@@ -307,6 +307,7 @@ _evas_cache2_image_preloaded_cb(void *data, Eina_Bool 
success)
 
ie->cache2->preload = eina_list_remove(ie->cache2->preload, ie);
ie->flags.preload_done = success;
+   ie->flags.updated_data = EINA_TRUE;
 
while ((tmp = ie->targets))
  {
diff --git a/src/lib/evas/cache2/evas_cache2.h 
b/src/lib/evas/cache2/evas_cache2.h
index 7cd9c79..6c7f5f8 100644
--- a/src/lib/evas/cache2/evas_cache2.h
+++ b/src/lib/evas/cache2/evas_cache2.h
@@ -66,6 +66,7 @@ EAPI void evas_cache2_image_close(Image_Entry *im);
 EAPI int evas_cache2_image_load_data(Image_Entry *ie);
 EAPI void evas_cache2_image_unload_data(Image_Entry *im);
 EAPI void evas_cache2_image_preload_data(Image_Entry *im, const void *target);
+EAPI void evas_cache2_image_preload_cancel(Image_Entry *im, const void 
*target);
 EAPI void evas_cache2_image_cache_key_create(char *hkey, const char *path, 
size_t pathlen, const char *key, size_t keylen, const Evas_Image_Load_Opts *lo);
 
 EAPI DATA32 * evas_cache2_image_pixels(Image_Entry *im);
diff --git a/src/modules/evas/engines/gl_common/evas_gl_image.c 
b/src/modules/evas/engines/gl_common/evas_gl_image.c
index 36b40aa..169b486 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_image.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_image.c
@@ -8,6 +8,12 @@ void
 evas_gl_common_image_alloc_ensure(Evas_GL_Image *im)
 {
if (!im->im) return;
+#ifdef EVAS_CSERVE2
+   if (evas_cache2_image_cached(&im->im->cache_entry))
+ im->im = (RGBA_Image *)evas_cache2_image_size_set(&im->im->cache_entry,
+im->w, im->h);
+   else
+#endif
im->im = (RGBA_Image *)evas_cache_image_size_set(&im->im->cache_entry,
 im->w, im->h);
 }
diff --git a/src/modules/evas/engines/gl_common/evas_gl_preload.c 
b/src/modules/evas/engines/gl_common/evas_gl_preload.c
index bdaa8de..5ee36b6 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_preload.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_preload.c
@@ -1,5 +1,9 @@
 #include "evas_gl_private.h"
 
+#ifdef EVAS_CSERVE2
+#include "evas_cs2_private.h"
+#endif
+
 static Eina_Thread async_loader_thread;
 static Eina_Condition async_loader_cond;
 static Eina_Lock async_loader_lock;
@@ -50,6 +54,11 @@ evas_gl_preload_pop(Evas_GL_Texture *tex)
 if (running) evas_gl_preload_render_lock(tmp_cb, tmp_data);
 
 evas_gl_common_texture_free(async_current->tex, EINA_FALSE);
+#ifdef EVAS_CSERVE2
+if (evas_cache2_image_cached(&async_current->im->cache_entry))
+  evas_cache2_image_close(&async_current->im->cache_entry);
+else
+#endif
 evas_cache_image_drop(&async_current->im->cache_entry);
 free(async_current);
 
@@ -66,6 +75,11 @@ evas_gl_preload_pop(Evas_GL_Texture *tex)
   async_loader_tex = eina_list_remove_list(async_loader_tex, l);
   
   evas_gl_common_texture_free(async->tex, EINA_FALSE);
+#ifdef EVAS_CSERVE2
+if (evas_cache2_image_cached(&async->im->cache_entry))
+  evas_cache2_image_close(&async->im->cache_entry);
+else
+#endif
   evas_cache_image_drop(&async->im->cache_entry);
   free(async);
 
@@ -100,6 +114,11 @@ _evas_gl_preload_main_loop_wakeup(void)
 async->tex->aptt = NULL;
 
 evas_gl_common_texture_free(async->tex, EINA_FALSE);
+#ifdef EVAS_CSERVE2
+if (evas_cache2_image_cached(&async->im->cache_entry))
+  evas_cache2_image_close(&async->im->cache_entry);
+else
+#endif
 evas_cache_image_drop(&async->im->cache_entry);
 free(async);
  }
diff --git a/src/modules/evas/engines/gl_common/evas_gl_texture.c 
b/src/modules/evas/engines/gl_common/evas_gl_texture.c
index e254db5..1cacce3 100644
--- a/src/modules/evas/engin

[EGIT] [core/efl] master 02/04: evas/cserve2: Fix crash in server when an image file changes

[Jean-Philippe Andre]

jpeg pushed a commit to branch master.

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

commit 2b8e74e623c33c1f218f7eec6d3ff6eea2d2b09d
Author: Jean-Philippe Andre 
Date:   Tue Oct 29 19:45:13 2013 +0900

evas/cserve2: Fix crash in server when an image file changes

Since cserve2 uses inotify to track image file updates,
it will drop its references to a specific file and all
the associated images.
Fix some logic in the deletion code.
---
 src/bin/evas/evas_cserve2_cache.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/src/bin/evas/evas_cserve2_cache.c 
b/src/bin/evas/evas_cserve2_cache.c
index 4c20a72..4322be2 100644
--- a/src/bin/evas/evas_cserve2_cache.c
+++ b/src/bin/evas/evas_cserve2_cache.c
@@ -1075,9 +1075,12 @@ _image_entry_free(Image_Entry *ientry)
if (fd)
  {
 fentry = _file_entry_find(fd->id);
-fentry->images = eina_list_remove(fentry->images, ientry);
-if (fentry && !fentry->images && !ASENTRY(fentry)->references)
-  eina_hash_del_by_key(file_entries, &fd->id);
+if (fentry)
+  {
+ fentry->images = eina_list_remove(fentry->images, ientry);
+ if (!fentry->images && !ASENTRY(fentry)->references)
+   eina_hash_del_by_key(file_entries, &fd->id);
+  }
  }
else
   ERR("Could not find file data %u for image %u",
@@ -1669,18 +1672,14 @@ static void
 _file_changed_cb(const char *path EINA_UNUSED, Eina_Bool deleted EINA_UNUSED, 
void *data)
 {
File_Watch *fw = data;
-   File_Data *fd;
+   File_Entry *fentry;
Eina_List *l;
 
-   EINA_LIST_FOREACH(fw->entries, l, fd)
+   EINA_LIST_FOREACH(fw->entries, l, fentry)
  {
 Eina_List *ll;
 Image_Entry *ie;
-File_Entry *fentry;
-
-fd->invalid = EINA_TRUE;
-fentry = _file_entry_find(fd->id);
-if (!fentry) continue;
+File_Data *fd;
 
 fentry->watcher = NULL;
 
@@ -1688,13 +1687,13 @@ _file_changed_cb(const char *path EINA_UNUSED, 
Eina_Bool deleted EINA_UNUSED, vo
   {
  Image_Data *idata;
 
+ idata = _image_data_find(ENTRYID(ie));
  eina_hash_set(image_entries, &ENTRYID(ie), NULL);
  if (ASENTRY(ie)->request /*&& !ie->base.request->processing*/)
cserve2_request_cancel_all(ASENTRY(ie)->request,
   CSERVE2_FILE_CHANGED);
  ASENTRY(ie)->request = NULL;
 
- idata = _image_data_find(ENTRYID(ie));
  if (idata)
{
   _image_id_free(idata);
@@ -1703,8 +1702,15 @@ _file_changed_cb(const char *path EINA_UNUSED, Eina_Bool 
deleted EINA_UNUSED, vo
}
   }
 
-_file_id_free(fd);
-eina_hash_set(file_entries, &fd->id, NULL);
+
+fd = _file_data_find(ENTRYID(fentry));
+if (fd)
+  {
+ fd->invalid = EINA_TRUE;
+ _file_id_free(fd);
+ eina_hash_set(file_entries, &fd->id, NULL);
+  }
+
 if (ASENTRY(fentry)->request
 /*&& !ASENTRY(fentry)->request->processing*/)
   {

-- 

Re: [E-devel] Is there *real* documentation for edje?

[Eduardo Lima (Etrunko)]

On Wed, Oct 30, 2013 at 7:44 AM, Carsten Haitzler  wrote:
> On Wed, 30 Oct 2013 09:07:29 + Andrew F  
> said:
>
>> ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png  is working.
>
> not here - not when i have to go via a squid proxy...
>

Good guy Etrunko fixes for you http://imgur.com/8QsDEmc


> Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without
> sending any data.
>
> but i guessed on what he wanted to do anyway... ie the windows start menu with
> its multiple columns of varying info... :)
>
>> On Wed, Oct 30, 2013 at 3:30 AM, Carsten Haitzler 
>> wrote:
>>
>> > On Tue, 29 Oct 2013 15:14:07 -0400 Robert Heller 
>> > said:
>> >
>> > > I am trying to write an alternitive version of the Enlightenment's 'start
>> > > menu', where instead of a cascade menu it is a three column thingy (I am
>> > not
>> > > sure what this sort of menu is called), something like this (from Mint):
>> > >
>> > > ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
>> >
>> > well that link doesn't work... no data. :)
>> >
>> > > But I am having a hard time figuring out how to do this.  The
>> > documentation
>> > > for edje leaves a lot to be desired and the API for enlightenment itself
>> > is
>> > > pretty much not documented at all.  I am a skilled C programmer, but
>> > without
>> > > useful documentation it is very hard to program...
>> >
>> > edje has a full reference. people have pointed to it already. there are
>> > intro
>> > docs all around. but like most things - the rest is "look at examples and
>> > build
>> > from there". i personally find documentation obtuse and wasteful compared
>> > to
>> > examples. you may perfer wandering through docs. i spent my early unix
>> > learning
>> > years reading every manual page i could find - but frankly, reading someone
>> > elses shell scripts and then just referring to a manual for reference was
>> > by
>> > far easier and more productive..
>> >
>> > now what i think your core problem here is, that you can't figure out how
>> > to do
>> > what you want.. because you literally can't do it in edje. you want to
>> > fundamentally change the behaviour and layout of a menu. not just
>> > re-shuffle
>> > some things, but change its core and that means you need to head off into
>> > the
>> > land of code. e_menu.c is where the entire menu code is. you wish to have
>> > similar functionality but different arrangement and that is a whole new
>> > kettle
>> > of fish. edje is merely a building-block to produce the gui elements you
>> > then
>> > lay out in code.
>> >
>> > --
>> > - Codito, ergo sum - "I code, therefore I am" --
>> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
>> >
>> >
>> >
>> > --
>> > Android is increasing in popularity, but the open development platform that
>> > developers love is also attractive to malware creators. Download this white
>> > paper to learn more about secure code signing practices that can help keep
>> > Android apps secure.
>> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> > ___
>> > enlightenment-devel mailing list
>> > enlightenment-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> >
>> --
>> Android is increasing in popularity, but the open development platform that
>> developers love is also attractive to malware creators. Download this white
>> paper to learn more about secure code signing practices that can help keep
>> Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Eduardo de Barros Lima ◤✠◢
ebl...@gmail.com

--
Android is increasing in popularity, but the open development platform that
developers love is als

Re: [E-devel] Is there *real* documentation for edje?

[The Rasterman]

On Wed, 30 Oct 2013 09:46:35 -0200 "Eduardo Lima (Etrunko)" 
said:

> On Wed, Oct 30, 2013 at 7:44 AM, Carsten Haitzler 
> wrote:
> > On Wed, 30 Oct 2013 09:07:29 + Andrew F 
> > said:
> >
> >> ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png  is working.
> >
> > not here - not when i have to go via a squid proxy...
> >
> 
> Good guy Etrunko fixes for you http://imgur.com/8QsDEmc

thanks good guy!

> > Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection
> > without sending any data.
> >
> > but i guessed on what he wanted to do anyway... ie the windows start menu
> > with its multiple columns of varying info... :)
> >
> >> On Wed, Oct 30, 2013 at 3:30 AM, Carsten Haitzler
> >> wrote:
> >>
> >> > On Tue, 29 Oct 2013 15:14:07 -0400 Robert Heller 
> >> > said:
> >> >
> >> > > I am trying to write an alternitive version of the Enlightenment's
> >> > > 'start menu', where instead of a cascade menu it is a three column
> >> > > thingy (I am
> >> > not
> >> > > sure what this sort of menu is called), something like this (from
> >> > > Mint):
> >> > >
> >> > > ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
> >> >
> >> > well that link doesn't work... no data. :)
> >> >
> >> > > But I am having a hard time figuring out how to do this.  The
> >> > documentation
> >> > > for edje leaves a lot to be desired and the API for enlightenment
> >> > > itself
> >> > is
> >> > > pretty much not documented at all.  I am a skilled C programmer, but
> >> > without
> >> > > useful documentation it is very hard to program...
> >> >
> >> > edje has a full reference. people have pointed to it already. there are
> >> > intro
> >> > docs all around. but like most things - the rest is "look at examples and
> >> > build
> >> > from there". i personally find documentation obtuse and wasteful compared
> >> > to
> >> > examples. you may perfer wandering through docs. i spent my early unix
> >> > learning
> >> > years reading every manual page i could find - but frankly, reading
> >> > someone elses shell scripts and then just referring to a manual for
> >> > reference was by
> >> > far easier and more productive..
> >> >
> >> > now what i think your core problem here is, that you can't figure out how
> >> > to do
> >> > what you want.. because you literally can't do it in edje. you want to
> >> > fundamentally change the behaviour and layout of a menu. not just
> >> > re-shuffle
> >> > some things, but change its core and that means you need to head off into
> >> > the
> >> > land of code. e_menu.c is where the entire menu code is. you wish to have
> >> > similar functionality but different arrangement and that is a whole new
> >> > kettle
> >> > of fish. edje is merely a building-block to produce the gui elements you
> >> > then
> >> > lay out in code.
> >> >
> >> > --
> >> > - Codito, ergo sum - "I code, therefore I am" --
> >> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >> >
> >> >
> >> >
> >> > --
> >> > Android is increasing in popularity, but the open development platform
> >> > that developers love is also attractive to malware creators. Download
> >> > this white paper to learn more about secure code signing practices that
> >> > can help keep Android apps secure.
> >> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> >> > ___
> >> > enlightenment-devel mailing list
> >> > enlightenment-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >
> >> --
> >> Android is increasing in popularity, but the open development platform that
> >> developers love is also attractive to malware creators. Download this white
> >> paper to learn more about secure code signing practices that can help keep
> >> Android apps secure.
> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> > --
> > Android is increasing in popularity, but the open development platform that
> > developers love is also attractive to malware creators. Download this white
> > paper to learn more about secure code signing practices that can help keep
> > Android apps secure.
> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enligh

[EGIT] [core/elementary] master 01/01: remove +x bit from .c file!

[Rasterman]

raster pushed a commit to branch master.

http://git.enlightenment.org/core/elementary.git/commit/?id=10dcfbea60e2ca19dce87f53244573b565355c89

commit 10dcfbea60e2ca19dce87f53244573b565355c89
Author: Carsten Haitzler (Rasterman) 
Date:   Wed Oct 30 21:28:01 2013 +0900

remove +x bit from .c file!
---
 src/bin/test_image.c | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/src/bin/test_image.c b/src/bin/test_image.c
old mode 100755
new mode 100644

-- 

Re: [E-devel] Is there *real* documentation for edje?

[Robert Heller]

At Wed, 30 Oct 2013 12:30:54 +0900 Carsten Haitzler (The Rasterman) 
 wrote:

> 
> On Tue, 29 Oct 2013 15:14:07 -0400 Robert Heller  said:
> 
> > I am trying to write an alternitive version of the Enlightenment's 'start 
> > menu', where instead of a cascade menu it is a three column thingy (I am 
> > not 
> > sure what this sort of menu is called), something like this (from Mint):
> > 
> > ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
> 
> well that link doesn't work... no data. :)

Wrong URL (bad copy-paste).  The correct URL is:

ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png

> 
> > But I am having a hard time figuring out how to do this.  The documentation 
> > for edje leaves a lot to be desired and the API for enlightenment itself is 
> > pretty much not documented at all.  I am a skilled C programmer, but 
> > without 
> > useful documentation it is very hard to program...
> 
> edje has a full reference. people have pointed to it already. there are intro
> docs all around. but like most things - the rest is "look at examples and 
> build
> from there". i personally find documentation obtuse and wasteful compared to
> examples. you may perfer wandering through docs. i spent my early unix 
> learning
> years reading every manual page i could find - but frankly, reading someone
> elses shell scripts and then just referring to a manual for reference was by
> far easier and more productive..

The PDF file generated from the LaTeX is only examples -- there isn't a 
*reference*. I found the *examples* by themselves to be less than useful, 
since there didn't seem to be a good *concept* reference.  At least in the PDF 
file I ended up with (make doc; cd doc/latex; make refman.pdf).

> 
> now what i think your core problem here is, that you can't figure out how to 
> do
> what you want.. because you literally can't do it in edje. you want to
> fundamentally change the behaviour and layout of a menu. not just re-shuffle
> some things, but change its core and that means you need to head off into the
> land of code. e_menu.c is where the entire menu code is. you wish to have
> similar functionality but different arrangement and that is a whole new kettle
> of fish. edje is merely a building-block to produce the gui elements you then
> lay out in code.

I know all of that -- I am writting C code to implement the alternitive 
functionallity, but it seems that I need some edje code  to go with it.

> 

-- 
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


   

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there *real* documentation for edje?

[Robert Heller]

At Wed, 30 Oct 2013 11:21:35 +0900 Enlightenment developer list 
 wrote:

> 
> Hello,
> 
> On Wed, Oct 30, 2013 at 6:04 AM, Guillaume Friloux
>  wrote:
> > Le 29/10/2013 20:14, Robert Heller a écrit :
> >> I am trying to write an alternitive version of the Enlightenment's 'start
> >> menu', where instead of a cascade menu it is a three column thingy (I am 
> >> not
> >> sure what this sort of menu is called), something like this (from Mint):
> >>
> >> ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
> >>
> >> But I am having a hard time figuring out how to do this.  The documentation
> >> for edje leaves a lot to be desired and the API for enlightenment itself is
> >> pretty much not documented at all.  I am a skilled C programmer, but 
> >> without
> >> useful documentation it is very hard to program...
> >>
> > For people trying to look linked image :
> > ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png
> > As i am not involved in GUI libs of EFLs, ill let others answer you.
> 
> I am not sure this is doable with just theme in E. It seems to not
> only change the look of the menu, but also its navigation. I may be
> wrong, but it may require to write a new module to have this specific
> menu.

I am writing C code to display this, but it seems that I need an edje file to 
support the C code.

-- 
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


 

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/03: async render -> alpha set. if not visible dont WAIT. do it now.

[Ulisses Furquim]

Hi Raster,

On Tue, Oct 29, 2013 at 11:35 AM, Carsten Haitzler  wrote:
> On Tue, 29 Oct 2013 10:20:33 -0200 Ulisses Furquim  said:
>
>> Raster,
>>
>> On Mon, Oct 28, 2013 at 10:03 PM, Carsten Haitzler 
>> wrote:
>> > On Mon, 28 Oct 2013 17:13:08 -0200 Ulisses Furquim 
>> > said:
>> >
>> >> Hi Raster,
>> >>
>> >> On Mon, Oct 28, 2013 at 12:47 AM, Carsten Haitzler 
>> >> wrote:
>> >> > On Fri, 18 Oct 2013 15:19:00 -0300 Ulisses Furquim 
>> >> > said:
>> >> >
>> >> >> Raster,
>> >> >>
>> >> >> On Wed, Oct 16, 2013 at 8:58 PM, Carsten Haitzler 
>> >> >> 
>> >> >> wrote:
>> >> >> > On Wed, 16 Oct 2013 12:26:26 -0300 Ulisses Furquim
>> >> >> >  said:
>> >> >> >
>> >> >> >> Raster,
>> >> >> >>
>> >> >> >> On Wed, Oct 16, 2013 at 12:01 PM, Carsten Haitzler
>> >> >> >>  wrote:
>> >> >> >> > raster pushed a commit to branch master.
>> >> >> >> >
>> >> >> >> > http://git.enlightenment.org/core/efl.git/commit/?id=06c3c0cd0c0e2af7279470ab5b3fd3100e1499db
>> >> >> >> >
>> >> >> >> > commit 06c3c0cd0c0e2af7279470ab5b3fd3100e1499db
>> >> >> >> > Author: Carsten Haitzler (Rasterman) 
>> >> >> >> > Date:   Thu Oct 17 00:00:05 2013 +0900
>> >> >> >> >
>> >> >> >> > async render -> alpha set. if not visible dont WAIT. do it 
>> >> >> >> > now.
>> >> >> >> > ---
>> >> >> >> >  src/modules/ecore_evas/engines/x/ecore_evas_x.c | 11 ---
>> >> >> >> >  1 file changed, 8 insertions(+), 3 deletions(-)
>> >> >> >> >
>> >> >> >> > diff --git a/src/modules/ecore_evas/engines/x/ecore_evas_x.c
>> >> >> >> > b/src/modules/ecore_evas/engines/x/ecore_evas_x.c index
>> >> >> >> > 627dd15..69e0709 100644
>> >> >> >> > --- a/src/modules/ecore_evas/engines/x/ecore_evas_x.c
>> >> >> >> > +++ b/src/modules/ecore_evas/engines/x/ecore_evas_x.c
>> >> >> >> > @@ -2284,10 +2284,15 @@ _ecore_evas_x_alpha_set(Ecore_Evas *ee, 
>> >> >> >> > int
>> >> >> >> > alpha) {
>> >> >> >> >  if (ee->in_async_render)
>> >> >> >> >{
>> >> >> >> > - ee->delayed.alpha = alpha;
>> >> >> >> > - ee->delayed.alpha_changed = EINA_TRUE;
>> >> >> >> > - return;
>> >> >> >> > + if (ee->visible)
>> >> >> >> > +   {
>> >> >> >> > +  ee->delayed.alpha = alpha;
>> >> >> >> > +  ee->delayed.alpha_changed = EINA_TRUE;
>> >> >> >> > +  return;
>> >> >> >> > +   }
>> >> >> >> >}
>> >> >> >> > +if (ee->in_async_render)
>> >> >> >> > +evas_sync(ee->evas);
>> >> >> >>
>> >> >> >> Why? We're syncing just to apply the alpha for those not visible?
>> >> >> >> Your commit message is wrong because we are WAITING on this sync 
>> >> >> >> call
>> >> >> >> before the _alpha_do(). Thus it's almost the same as letting the
>> >> >> >> alpha be set the delayed way. Unless I'm missing anything we're not
>> >> >> >> gaining anything with this patch.
>> >> >> >
>> >> >> > no sync -> segv. sync -> no segv. (inside evas async rendering where
>> >> >> > an xob is null). since changing to alpha destroys and recreates the
>> >> >> > window id... not surprising.
>> >> >>
>> >> >> Do you have a backtrace? I did some quick testing but no segv for me.
>> >> >
>> >> > i did have one... it was in the async "flush" code - the one where the
>> >> > mainloop inline does its putimage to the window... but the xob was NULL
>> >> > (i didn't even check more than that because i instantly had the twinge
>> >> > that "h i bet the xob creation failed due to invalid window id or
>> >> > something and thus why its null.. when the code is ASSUMING window id
>> >> > doesnt change during rendering"... thus simple - ensure rendering is
>> >> > done before we change window id. :)
>> >>
>> >> Window ID shouldn't change during rendering, that's the point of
>> >> having delayed operations. :-) Like Gustavo said I'm interested to
>> >> know what really was the problem because I don't think we should be
>> >> solving everything by adding evas_sync() calls everywhere.
>> >
>> > the window id does change. that's the core issue here. it is destroyed and
>> > re-created as that is the only way we can switch the visual of the window 
>> > :)
>> > (given ecore-x). thus why i forced the "wait for async to finish"... :) 
>> > also
>> > remember any properties set on the window before are then lost and we rely
>> > on ecore-evas to restore the ones it knows about (and has remembered to
>> > restore).
>>
>> *During* rendering it shouldn't, have you read what I wrote?! :-)
>
> yes - i read it... but it DOES ... if you make the changes and remove the
> deferred change in alpha and do it there and then. i made that change before
> any commit made it anywhere... and segv land it was. thus need to sync and 
> wait
> so rendering is done - then window can be destroyed+created safely.

It may be that only me was confused but just now I realize what you're
trying to do. And yes, if you don't defer the alpha change and don't
wait the rendering to finish it's really prone 

Re: [E-devel] [EGIT] [core/efl] master 03/03: async render -> alpha set. if not visible dont WAIT. do it now.

[Ulisses Furquim]

Hi Stefan,

On Tue, Oct 29, 2013 at 12:01 PM, Stefan Schmidt  wrote:
> Hello.
>
> Mike requested me to let you know that he also explains things in his
> second reply (16.10.2013) which you seem to ignore.

Yeah, I was confused by the crash mentioned by Raster, but now I
understand the real problem and Mike did say that in his e-mail. I'm
still not sure why we were having that.

> On 10/29/2013 12:20 PM, Ulisses Furquim wrote:
>
> [snap]
>
>> I was trying to understand the bug being fixed and yes, it's minor and
>> I can just leave it as that. However, we need to improve the way we do
>> development as an open source project. It's kind of embarrassing that
>> we don't have proper usage of version control, good commit messages,
>> reviews, release schedule and so on. :-/
>
> And you thing that will improve just by complaining about it? It will
> definitely not. It only improves if you actively work on changing
> things. I few examples for you what did improve over the last 1.5 years:
>
> o Daniel and Tom migrated us over to git and helped people with using is
> as well as bringing in best practices piece by piece (developer repos
> and branches, possible merge work flows, complains about commit messages)
>
> o Daniel and I did a lot of work to get CI up to speed and improved it
> in various ways
>
> o I started to do coverity builds and other QA stuff to raise awareness

You did great, really.

> o During the latest dev day we discussed about release and raster
> suggested a time based schedule (just think about this. I would never
> seen that coming some time ago). I signed up for doing the first trial
> of this for the 1.9 efl release.

So I heard from Sachiel. It's great and it's what we've been asking
Raster for a quite long time. :-)

> That are just a few things. I actually think we improved a lot over the
> last 1.5 years. Still not where I want us to be but we are making more
> progress than I hoped for.

Agreed.

> All things only works if someone steps up and ACTIVELY does something.
> You want more review? Great! There has been a chance with the cserv2
> branch just recently but nobody really did a public review. I see you
> doing reviews on the async stuff which is good but if you want more
> people doing it you need to lead by doing so yourself even on other patches.

Yes, I'm not arguing here. And each one is putting the time it has
available on the project. Thus that's why I mentioned commit messages,
splitting better the patches and so on, because all of this make the
life of whoever is reviewing easier.

> Don't complain about everything is shitty just because you don't like
> how this one patch was handled. Look at the whole picture and improve by
> actively helping out where help is needed. And yes, we should discuss
> this in a different thread

Oops, I didn't start a new thread and I'm not sure if we need one. My
rant was broader that it had to be, but it seems we agree there's
still a lot of room for improvements.

Thanks,

-- Ulisses

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there *real* documentation for edje?

[The Rasterman]

On Wed, 30 Oct 2013 08:47:22 -0400 Robert Heller  said:

> At Wed, 30 Oct 2013 11:21:35 +0900 Enlightenment developer list
>  wrote:
> 
> > 
> > Hello,
> > 
> > On Wed, Oct 30, 2013 at 6:04 AM, Guillaume Friloux
> >  wrote:
> > > Le 29/10/2013 20:14, Robert Heller a écrit :
> > >> I am trying to write an alternitive version of the Enlightenment's 'start
> > >> menu', where instead of a cascade menu it is a three column thingy (I am
> > >> not sure what this sort of menu is called), something like this (from
> > >> Mint):
> > >>
> > >> ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
> > >>
> > >> But I am having a hard time figuring out how to do this.  The
> > >> documentation for edje leaves a lot to be desired and the API for
> > >> enlightenment itself is pretty much not documented at all.  I am a
> > >> skilled C programmer, but without useful documentation it is very hard
> > >> to program...
> > >>
> > > For people trying to look linked image :
> > > ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png
> > > As i am not involved in GUI libs of EFLs, ill let others answer you.
> > 
> > I am not sure this is doable with just theme in E. It seems to not
> > only change the look of the menu, but also its navigation. I may be
> > wrong, but it may require to write a new module to have this specific
> > menu.
> 
> I am writing C code to display this, but it seems that I need an edje file to 
> support the C code.

you dont NEED it... butr we do use it everywhere as a way to abstract the
skinning and look, events and animation stuff. :)

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


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[The Rasterman]

On Wed, 30 Oct 2013 08:47:23 -0400 Robert Heller  said:

> At Wed, 30 Oct 2013 12:30:54 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > 
> > On Tue, 29 Oct 2013 15:14:07 -0400 Robert Heller  said:
> > 
> > > I am trying to write an alternitive version of the Enlightenment's 'start 
> > > menu', where instead of a cascade menu it is a three column thingy (I am
> > > not sure what this sort of menu is called), something like this (from
> > > Mint):
> > > 
> > > ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
> > 
> > well that link doesn't work... no data. :)
> 
> Wrong URL (bad copy-paste).  The correct URL is:
> 
> ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png
> 
> > 
> > > But I am having a hard time figuring out how to do this.  The
> > > documentation for edje leaves a lot to be desired and the API for
> > > enlightenment itself is pretty much not documented at all.  I am a
> > > skilled C programmer, but without useful documentation it is very hard to
> > > program...
> > 
> > edje has a full reference. people have pointed to it already. there are
> > intro docs all around. but like most things - the rest is "look at examples
> > and build from there". i personally find documentation obtuse and wasteful
> > compared to examples. you may perfer wandering through docs. i spent my
> > early unix learning years reading every manual page i could find - but
> > frankly, reading someone elses shell scripts and then just referring to a
> > manual for reference was by far easier and more productive..
> 
> The PDF file generated from the LaTeX is only examples -- there isn't a 
> *reference*. I found the *examples* by themselves to be less than useful, 
> since there didn't seem to be a good *concept* reference.  At least in the
> PDF file I ended up with (make doc; cd doc/latex; make refman.pdf).
> 
> > 
> > now what i think your core problem here is, that you can't figure out how
> > to do what you want.. because you literally can't do it in edje. you want to
> > fundamentally change the behaviour and layout of a menu. not just re-shuffle
> > some things, but change its core and that means you need to head off into
> > the land of code. e_menu.c is where the entire menu code is. you wish to
> > have similar functionality but different arrangement and that is a whole
> > new kettle of fish. edje is merely a building-block to produce the gui
> > elements you then lay out in code.
> 
> I know all of that -- I am writting C code to implement the alternitive 
> functionallity, but it seems that I need some edje code  to go with it.

given what you want is still a menu you can re-use the existing edje
groups/parts for now until you have wrapped your head around edje. trust me -
it's not something a document will tell you or teach you. it's cold hard slog
and experience that will. :)


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


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/03: async render -> alpha set. if not visible dont WAIT. do it now.

[The Rasterman]

On Wed, 30 Oct 2013 11:29:57 -0200 Ulisses Furquim  said:

> Hi Raster,
> 
> On Tue, Oct 29, 2013 at 11:35 AM, Carsten Haitzler 
> wrote:
> > On Tue, 29 Oct 2013 10:20:33 -0200 Ulisses Furquim 
> > said:
> >
> >> Raster,
> >>
> >> On Mon, Oct 28, 2013 at 10:03 PM, Carsten Haitzler 
> >> wrote:
> >> > On Mon, 28 Oct 2013 17:13:08 -0200 Ulisses Furquim 
> >> > said:
> >> >
> >> >> Hi Raster,
> >> >>
> >> >> On Mon, Oct 28, 2013 at 12:47 AM, Carsten Haitzler
> >> >>  wrote:
> >> >> > On Fri, 18 Oct 2013 15:19:00 -0300 Ulisses Furquim
> >> >> >  said:
> >> >> >
> >> >> >> Raster,
> >> >> >>
> >> >> >> On Wed, Oct 16, 2013 at 8:58 PM, Carsten Haitzler
> >> >> >>  wrote:
> >> >> >> > On Wed, 16 Oct 2013 12:26:26 -0300 Ulisses Furquim
> >> >> >> >  said:
> >> >> >> >
> >> >> >> >> Raster,
> >> >> >> >>
> >> >> >> >> On Wed, Oct 16, 2013 at 12:01 PM, Carsten Haitzler
> >> >> >> >>  wrote:
> >> >> >> >> > raster pushed a commit to branch master.
> >> >> >> >> >
> >> >> >> >> > http://git.enlightenment.org/core/efl.git/commit/?id=06c3c0cd0c0e2af7279470ab5b3fd3100e1499db
> >> >> >> >> >
> >> >> >> >> > commit 06c3c0cd0c0e2af7279470ab5b3fd3100e1499db
> >> >> >> >> > Author: Carsten Haitzler (Rasterman) 
> >> >> >> >> > Date:   Thu Oct 17 00:00:05 2013 +0900
> >> >> >> >> >
> >> >> >> >> > async render -> alpha set. if not visible dont WAIT. do it
> >> >> >> >> > now.
> >> >> >> >> > ---
> >> >> >> >> >  src/modules/ecore_evas/engines/x/ecore_evas_x.c | 11 +++
> >> >> >> >> > +--- 1 file changed, 8 insertions(+), 3 deletions(-)
> >> >> >> >> >
> >> >> >> >> > diff --git a/src/modules/ecore_evas/engines/x/ecore_evas_x.c
> >> >> >> >> > b/src/modules/ecore_evas/engines/x/ecore_evas_x.c index
> >> >> >> >> > 627dd15..69e0709 100644
> >> >> >> >> > --- a/src/modules/ecore_evas/engines/x/ecore_evas_x.c
> >> >> >> >> > +++ b/src/modules/ecore_evas/engines/x/ecore_evas_x.c
> >> >> >> >> > @@ -2284,10 +2284,15 @@ _ecore_evas_x_alpha_set(Ecore_Evas *ee,
> >> >> >> >> > int alpha) {
> >> >> >> >> >  if (ee->in_async_render)
> >> >> >> >> >{
> >> >> >> >> > - ee->delayed.alpha = alpha;
> >> >> >> >> > - ee->delayed.alpha_changed = EINA_TRUE;
> >> >> >> >> > - return;
> >> >> >> >> > + if (ee->visible)
> >> >> >> >> > +   {
> >> >> >> >> > +  ee->delayed.alpha = alpha;
> >> >> >> >> > +  ee->delayed.alpha_changed = EINA_TRUE;
> >> >> >> >> > +  return;
> >> >> >> >> > +   }
> >> >> >> >> >}
> >> >> >> >> > +if (ee->in_async_render)
> >> >> >> >> > +evas_sync(ee->evas);
> >> >> >> >>
> >> >> >> >> Why? We're syncing just to apply the alpha for those not visible?
> >> >> >> >> Your commit message is wrong because we are WAITING on this sync
> >> >> >> >> call before the _alpha_do(). Thus it's almost the same as letting
> >> >> >> >> the alpha be set the delayed way. Unless I'm missing anything
> >> >> >> >> we're not gaining anything with this patch.
> >> >> >> >
> >> >> >> > no sync -> segv. sync -> no segv. (inside evas async rendering
> >> >> >> > where an xob is null). since changing to alpha destroys and
> >> >> >> > recreates the window id... not surprising.
> >> >> >>
> >> >> >> Do you have a backtrace? I did some quick testing but no segv for me.
> >> >> >
> >> >> > i did have one... it was in the async "flush" code - the one where the
> >> >> > mainloop inline does its putimage to the window... but the xob was
> >> >> > NULL (i didn't even check more than that because i instantly had the
> >> >> > twinge that "h i bet the xob creation failed due to invalid
> >> >> > window id or something and thus why its null.. when the code is
> >> >> > ASSUMING window id doesnt change during rendering"... thus simple -
> >> >> > ensure rendering is done before we change window id. :)
> >> >>
> >> >> Window ID shouldn't change during rendering, that's the point of
> >> >> having delayed operations. :-) Like Gustavo said I'm interested to
> >> >> know what really was the problem because I don't think we should be
> >> >> solving everything by adding evas_sync() calls everywhere.
> >> >
> >> > the window id does change. that's the core issue here. it is destroyed
> >> > and re-created as that is the only way we can switch the visual of the
> >> > window :) (given ecore-x). thus why i forced the "wait for async to
> >> > finish"... :) also remember any properties set on the window before are
> >> > then lost and we rely on ecore-evas to restore the ones it knows about
> >> > (and has remembered to restore).
> >>
> >> *During* rendering it shouldn't, have you read what I wrote?! :-)
> >
> > yes - i read it... but it DOES ... if you make the changes and remove the
> > deferred change in alpha and do it there and then. i made that change before
> > any commit made it anywhere... and segv land it was. thus need to sync and
> > wait so rendering is done - then window ca

Re: [E-devel] Is there *real* documentation for edje?

[Cedric BAIL]

On Wed, Oct 30, 2013 at 9:47 PM, Robert Heller  wrote:
> The PDF file generated from the LaTeX is only examples -- there isn't a
> *reference*. I found the *examples* by themselves to be less than useful,
> since there didn't seem to be a good *concept* reference.  At least in the PDF
> file I ended up with (make doc; cd doc/latex; make refman.pdf).

I must say that I am not surprised, I believe that nobody did test the
result of building the doc with the pdf backend for a long time. I do
even believe that we have html specific stuff in our doc. So if you
have patch for the latex backend, feel free to submit them.
-- 
Cedric BAIL

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [misc/entrance] master 01/01: entrance: many improvment * improve pam login * fix some profile mistake when login an user * use EINA_UNUSED * code refactoring * remove session log

[Cedric BAIL]

Hello,

Just skimming in that thread.

On Wed, Oct 30, 2013 at 10:21 AM, Michaël Bouchaud  wrote:
> As I'm the only one to work on this project, I don't see the benefit to
> make atomic commits.

I must say that I wont read that commit at it is way to big to digest
and understand. If it had been smaller I would have spend the time to
read some of them. The one that I am interested in. It would also help
new comer understand what is going on and so you may on the long run
get more help. Just saying that such commit are not inclusive and wont
get you much help. It may be that at this point of your project you
don't really want help, which could be the case and perfectly
acceptable. Just wanted to clarify your intention and the expectation
you could get from people around. In that case, I would second Stefan
and think it would it then more relevant to have it in your dev
directory. What do you think ?
-- 
Cedric BAIL

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[Robert Heller]

At Wed, 30 Oct 2013 22:42:36 +0900 Carsten Haitzler (The Rasterman) 
 wrote:

> 
> On Wed, 30 Oct 2013 08:47:23 -0400 Robert Heller  said:
> 
> > At Wed, 30 Oct 2013 12:30:54 +0900 Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > > 
> > > On Tue, 29 Oct 2013 15:14:07 -0400 Robert Heller  
> > > said:
> > > 
> > > > I am trying to write an alternitive version of the Enlightenment's 
> > > > 'start 
> > > > menu', where instead of a cascade menu it is a three column thingy (I am
> > > > not sure what this sort of menu is called), something like this (from
> > > > Mint):
> > > > 
> > > > ftp://ftp.deepsoft.com/ftp/pub/deepwoods/Other/RibbonMenu.png
> > > 
> > > well that link doesn't work... no data. :)
> > 
> > Wrong URL (bad copy-paste).  The correct URL is:
> > 
> > ftp://ftp.deepsoft.com/pub/deepwoods/Other/RibbonMenu.png
> > 
> > > 
> > > > But I am having a hard time figuring out how to do this.  The
> > > > documentation for edje leaves a lot to be desired and the API for
> > > > enlightenment itself is pretty much not documented at all.  I am a
> > > > skilled C programmer, but without useful documentation it is very hard 
> > > > to
> > > > program...
> > > 
> > > edje has a full reference. people have pointed to it already. there are
> > > intro docs all around. but like most things - the rest is "look at 
> > > examples
> > > and build from there". i personally find documentation obtuse and wasteful
> > > compared to examples. you may perfer wandering through docs. i spent my
> > > early unix learning years reading every manual page i could find - but
> > > frankly, reading someone elses shell scripts and then just referring to a
> > > manual for reference was by far easier and more productive..
> > 
> > The PDF file generated from the LaTeX is only examples -- there isn't a 
> > *reference*. I found the *examples* by themselves to be less than useful, 
> > since there didn't seem to be a good *concept* reference.  At least in the
> > PDF file I ended up with (make doc; cd doc/latex; make refman.pdf).
> > 
> > > 
> > > now what i think your core problem here is, that you can't figure out how
> > > to do what you want.. because you literally can't do it in edje. you want 
> > > to
> > > fundamentally change the behaviour and layout of a menu. not just 
> > > re-shuffle
> > > some things, but change its core and that means you need to head off into
> > > the land of code. e_menu.c is where the entire menu code is. you wish to
> > > have similar functionality but different arrangement and that is a whole
> > > new kettle of fish. edje is merely a building-block to produce the gui
> > > elements you then lay out in code.
> > 
> > I know all of that -- I am writting C code to implement the alternitive 
> > functionallity, but it seems that I need some edje code  to go with it.
> 
> given what you want is still a menu you can re-use the existing edje
> groups/parts for now until you have wrapped your head around edje. trust me -
> it's not something a document will tell you or teach you. it's cold hard slog
> and experience that will. :)

I am *trying* to do this, but all I am getting is a 1 pixel wide vertical
strip. I have pretty much copied e_menu.c (to a new C file) , but I suspect
that since the Evas_Object * structure does not match what e_menu.c was
creating and thus the corresponding edje menu.edc (copied to a new edc file)
structure, the result is not displaying anything (or not much). I *think* I
need to have the edje structure match the Evas_Object * structure, yes no? It
does not help much that the enlightenment C API is not partitularly well
documented either.

> 
> 

-- 
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments



 

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/03: async render -> alpha set. if not visible dont WAIT. do it now.

[Stefan Schmidt]

Hello.

On 10/30/2013 01:40 PM, Ulisses Furquim wrote:
> Hi Stefan,
>
> On Tue, Oct 29, 2013 at 12:01 PM, Stefan Schmidt 
> wrote:
>> Hello.
>>
>> Mike requested me to let you know that he also explains things in his
>> second reply (16.10.2013) which you seem to ignore.
>
> Yeah, I was confused by the crash mentioned by Raster, but now I
> understand the real problem and Mike did say that in his e-mail. I'm
> still not sure why we were having that.

At least it cleared some things up.

>> On 10/29/2013 12:20 PM, Ulisses Furquim wrote:
>>
>> [snap]
>>
>>> I was trying to understand the bug being fixed and yes, it's minor and
>>> I can just leave it as that. However, we need to improve the way we do
>>> development as an open source project. It's kind of embarrassing that
>>> we don't have proper usage of version control, good commit messages,
>>> reviews, release schedule and so on. :-/
>>
>> And you thing that will improve just by complaining about it? It will
>> definitely not. It only improves if you actively work on changing
>> things. I few examples for you what did improve over the last 1.5 years:
>>
>> o Daniel and Tom migrated us over to git and helped people with using is
>> as well as bringing in best practices piece by piece (developer repos
>> and branches, possible merge work flows, complains about commit
> messages)
>>
>> o Daniel and I did a lot of work to get CI up to speed and improved it
>> in various ways
>>
>> o I started to do coverity builds and other QA stuff to raise awareness
>
> You did great, really.
>
>> o During the latest dev day we discussed about release and raster
>> suggested a time based schedule (just think about this. I would never
>> seen that coming some time ago). I signed up for doing the first trial
>> of this for the 1.9 efl release.
>
> So I heard from Sachiel. It's great and it's what we've been asking
> Raster for a quite long time. :-)

Its a slow process but at least we are starting it now.

>> That are just a few things. I actually think we improved a lot over the
>> last 1.5 years. Still not where I want us to be but we are making more
>> progress than I hoped for.
>
> Agreed.
>
>> All things only works if someone steps up and ACTIVELY does something.
>> You want more review? Great! There has been a chance with the cserv2
>> branch just recently but nobody really did a public review. I see you
>> doing reviews on the async stuff which is good but if you want more
>> people doing it you need to lead by doing so yourself even on other
> patches.
>
> Yes, I'm not arguing here. And each one is putting the time it has
> available on the project. Thus that's why I mentioned commit messages,
> splitting better the patches and so on, because all of this make the
> life of whoever is reviewing easier.

Sure, I also try to push for that. But reality teaches me that this is 
also a very slow process and best brought forward by leading with 
examples. Even if every "mo mo mo" commit message from raster sets us 
back in this process. To be fair he also got a bit better with his 
messages. :)

>> Don't complain about everything is shitty just because you don't like
>> how this one patch was handled. Look at the whole picture and improve by
>> actively helping out where help is needed. And yes, we should discuss
>> this in a different thread
>
> Oops, I didn't start a new thread and I'm not sure if we need one. My
> rant was broader that it had to be, but it seems we agree there's
> still a lot of room for improvements.

There is. I just wanted to point out that we are making progress. I 
think we can close this part of the thred again now. :)

regards
Stefan Schmidt

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 02/09: edje: make setters for "edje_edit_state_color..." return Eina_Bool.

[Vorobiov Vitalii]

cedric pushed a commit to branch master.

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

commit 503cbbe80b432bb368bd16f2af4c63c873d1a610
Author: Vorobiov Vitalii 
Date:   Wed Oct 30 21:49:32 2013 +0900

edje: make setters for "edje_edit_state_color..." return Eina_Bool.

This patch start returning Eina_Bool for the following color setters to be
able to detect errors when calling them.
edje_edit_state_color_set
edje_edit_state_color2_set
edje_edit_state_color3_set

Reviewers: cedric, seoz

Reviewed By: cedric

CC: reutskiy.v.v

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Edit.h | 12 +---
 src/lib/edje/edje_edit.c | 32 +++-
 2 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 1c3f24f..18c31b8 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -1518,8 +1518,10 @@ EAPI void edje_edit_state_color3_get(Evas_Object *obj, 
const char *part, const c
  * @param g The green value of the color.
  * @param b The blue value of the color.
  * @param a The alpha value of the color.
+ *
+ * @return EINA_TRUE If successfull, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_state_color_set(Evas_Object *obj, const char *part, const 
char *state, double value, int r, int g, int b, int a);
+EAPI Eina_Bool edje_edit_state_color_set(Evas_Object *obj, const char *part, 
const char *state, double value, int r, int g, int b, int a);
 
 /** Set the color2 of a part state.
  *
@@ -1531,8 +1533,10 @@ EAPI void edje_edit_state_color_set(Evas_Object *obj, 
const char *part, const ch
  * @param g The green value of the color.
  * @param b The blue value of the color.
  * @param a The alpha value of the color.
+ *
+ * @return EINA_TRUE If successfull, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_state_color2_set(Evas_Object *obj, const char *part, const 
char *state, double value, int r, int g, int b, int a);
+EAPI Eina_Bool edje_edit_state_color2_set(Evas_Object *obj, const char *part, 
const char *state, double value, int r, int g, int b, int a);
 
 /** Set the color3 of a part state.
  *
@@ -1544,8 +1548,10 @@ EAPI void edje_edit_state_color2_set(Evas_Object *obj, 
const char *part, const c
  * @param g The green value of the color.
  * @param b The blue value of the color.
  * @param a The alpha value of the color.
+ *
+ * @return EINA_TRUE If successfull, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_state_color3_set(Evas_Object *obj, const char *part, const 
char *state, double value, int r, int g, int b, int a);
+EAPI Eina_Bool edje_edit_state_color3_set(Evas_Object *obj, const char *part, 
const char *state, double value, int r, int g, int b, int a);
 
 /** Get the horizontal align value of a part state.
  *
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index e72cf8e..a4fa0dc 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -3269,17 +3269,24 @@ FUNC_STATE_REL(rel2, y);
  if (b) *b = pd->Code.b;   \
  if (a) *a = pd->Code.a;   \
   }\
-  EAPI void\
+  EAPI Eina_Bool\
   edje_edit_state_##Code##_set(Evas_Object *obj, const char *part, const char 
*state, double value, int r, int g, int b, int a) \
   {\
- GET_PD_OR_RETURN();   \
+ if ((!obj) || (!part) || (!state)) \
+   return EINA_FALSE;   \
+ GET_PD_OR_RETURN(EINA_FALSE); \
\
- if (r > -1 && r < 256) pd->Code.r = r;\
- if (g > -1 && g < 256) pd->Code.g = g;\
- if (b > -1 && b < 256) pd->Code.b = b;\
- if (a > -1 && a < 256) pd->Code.a = a;\
+ if (r > -1 && r < 256) pd->Code.r = r; \
+ else return EINA_FALSE;\
+ if (g > -1 && g < 256) pd->Code.g = g; \
+ else return EINA_FALSE;\
+ if (b > -1 && b < 256) pd->Code.b = b; \
+ else return EINA_FALSE;\
+ if (a > -1 && a < 256) pd->Code.a = a; \
+ else return EINA_FALSE;\
   

[EGIT] [core/efl] master 01/09: edje: Make setters for "edje_edit_state_min/max..." return Eina_Bool

[Vorobiov Vitalii]

cedric pushed a commit to branch master.

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

commit 26cd65cfcb7605330133effc841baa8fac9e0131
Author: Vorobiov Vitalii 
Date:   Wed Oct 30 21:45:00 2013 +0900

edje: Make setters for "edje_edit_state_min/max..." return Eina_Bool

This patch start returning Eina_Bool for state's min and max value setters, 
so
we can now catch error when calling those function.
edje_edit_state_min_h_set
edje_edit_state_min_w_set
edje_edit_state_max_h_set
edje_edit_state_max_w_set

Reviewers: cedric, seoz

Reviewed By: cedric

CC: reutskiy.v.v

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Edit.h |  8 
 src/lib/edje/edje_edit.c | 20 
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 1a6d037..1c3f24f 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -1608,7 +1608,7 @@ EAPI int edje_edit_state_min_w_get(Evas_Object *obj, 
const char *part, const cha
  * @param value The state value.
  * @param min_w Minimum width value.
  */
-EAPI void edje_edit_state_min_w_set(Evas_Object *obj, const char *part, const 
char *state, double value, int min_w);
+EAPI Eina_Bool edje_edit_state_min_w_set(Evas_Object *obj, const char *part, 
const char *state, double value, int min_w);
 
 /** Get the minimum height value of a part state.
  *
@@ -1629,7 +1629,7 @@ EAPI int edje_edit_state_min_h_get(Evas_Object *obj, 
const char *part, const cha
  * @param value The state value.
  * @param min_h Minimum height value.
  */
-EAPI void edje_edit_state_min_h_set(Evas_Object *obj, const char *part, const 
char *state, double value, int min_h);
+EAPI Eina_Bool edje_edit_state_min_h_set(Evas_Object *obj, const char *part, 
const char *state, double value, int min_h);
 
 /** Get the maximum width value of a part state.
  *
@@ -1650,7 +1650,7 @@ EAPI int edje_edit_state_max_w_get(Evas_Object *obj, 
const char *part, const cha
  * @param value The state value.
  * @param max_w Maximum width value.
  */
-EAPI void edje_edit_state_max_w_set(Evas_Object *obj, const char *part, const 
char *state, double value, int max_w);
+EAPI Eina_Bool edje_edit_state_max_w_set(Evas_Object *obj, const char *part, 
const char *state, double value, int max_w);
 
 /** Get the maximum height value of a part state.
  *
@@ -1671,7 +1671,7 @@ EAPI int edje_edit_state_max_h_get(Evas_Object *obj, 
const char *part, const cha
  * @param value The state value.
  * @param max_h Maximum height value.
  */
-EAPI void edje_edit_state_max_h_set(Evas_Object *obj, const char *part, const 
char *state, double value, int max_h);
+EAPI Eina_Bool edje_edit_state_max_h_set(Evas_Object *obj, const char *part, 
const char *state, double value, int max_h);
 
 /** Get the minimum aspect value of a part state.
  *
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index 90cb4cf..e72cf8e 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -3346,27 +3346,31 @@ edje_edit_state_color3_set(Evas_Object *obj, const char 
*part, const char *state
  edje_object_calc_force(obj);  \
   }
 
-#define FUNC_STATE_INT(Class, Value)   \
+#define FUNC_STATE_INT(Class, Value, Min)  \
   EAPI int \
   edje_edit_state_##Class##_##Value##_get(Evas_Object *obj, const char *part, 
const char *state, double value) \
   {\
  GET_PD_OR_RETURN(0);  \
  return pd->Class.Value;   \
   }\
-  EAPI void\
+  EAPI Eina_Bool \
   edje_edit_state_##Class##_##Value##_set(Evas_Object *obj, const char *part, 
const char *state, double value, int v) \
   {\
- GET_PD_OR_RETURN();   \
- pd->Class.Value = v;  \
+ if ((!obj) || (!part) || (!state)) \
+   return EINA_FALSE;   \
+ if (v < Min) return EINA_FALSE;\
+ GET_PD_OR_RETURN(EINA_FALSE);  \
+ pd->Class.Value = v;  \
  edje_object_calc_force(obj);  \
+ return EINA_TRUE;  \
   }
 
 FUNC_STATE_DOUBLE(align, x);
 FUNC_STATE_DOUBLE(align, y

[EGIT] [core/efl] master 03/09: edje: make edje edit rel setters return Eina_Bool.

[Andrii Kroitor]

cedric pushed a commit to branch master.

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

commit 5d0e0c3f16c12fa7e26343bae019c6d622871540
Author: Andrii Kroitor 
Date:   Wed Oct 30 21:54:23 2013 +0900

edje: make edje edit rel setters return Eina_Bool.

Make the following function return an Eina_Bool so the caller can detect
errors if it want :
edje_edit_state_rel1_relative_x_set
edje_edit_state_rel1_relative_y_set
edje_edit_state_rel2_relative_x_set
edje_edit_state_rel2_relative_y_set
edje_edit_state_rel1_offset_x_set
edje_edit_state_rel1_offset_y_set
edje_edit_state_rel2_offset_x_set
edje_edit_state_rel2_offset_y_set
edje_edit_state_rel1_to_x_set
edje_edit_state_rel1_to_y_set
edje_edit_state_rel2_to_x_set
edje_edit_state_rel2_to_y_set

Reviewers: cedric, seoz

CC: reutskiy.v.v

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Edit.h |  48 ++
 src/lib/edje/edje_edit.c | 101 +++
 2 files changed, 82 insertions(+), 67 deletions(-)

diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 18c31b8..31ec1a9 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -1260,8 +1260,10 @@ EAPI double 
edje_edit_state_rel2_relative_y_get(Evas_Object *obj, const char *pa
  * @param state The name of the state to set 'rel1 relative X' (not including 
the state value).
  * @param value The state value.
  * @param x The new 'rel1 relative X' value to set'.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_state_rel1_relative_x_set(Evas_Object *obj, const char 
*part, const char *state, double value, double x);
+EAPI Eina_Bool edje_edit_state_rel1_relative_x_set(Evas_Object *obj, const 
char *part, const char *state, double value, double x);
 
 /** Set the 'rel1 relative Y' value of state.
  *
@@ -1270,8 +1272,10 @@ EAPI void 
edje_edit_state_rel1_relative_x_set(Evas_Object *obj, const char *part
  * @param state The name of the state to set 'rel1 relative Y' (not including 
the state value).
  * @param value The state value.
  * @param y The new 'rel1 relative Y' value to set'.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_state_rel1_relative_y_set(Evas_Object *obj, const char 
*part, const char *state, double value, double y);
+EAPI Eina_Bool edje_edit_state_rel1_relative_y_set(Evas_Object *obj, const 
char *part, const char *state, double value, double y);
 
 /** Set the 'rel2 relative X' value of state.
  *
@@ -1280,8 +1284,10 @@ EAPI void 
edje_edit_state_rel1_relative_y_set(Evas_Object *obj, const char *part
  * @param state The name of the state to set 'rel2 relative X' (not including 
the state value).
  * @param value The state value.
  * @param x The new 'rel2 relative X' value to set'.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_state_rel2_relative_x_set(Evas_Object *obj, const char 
*part, const char *state, double value, double x);
+EAPI Eina_Bool edje_edit_state_rel2_relative_x_set(Evas_Object *obj, const 
char *part, const char *state, double value, double x);
 
 /** Set the 'rel2 relative Y' value of state.
  *
@@ -1290,8 +1296,10 @@ EAPI void 
edje_edit_state_rel2_relative_x_set(Evas_Object *obj, const char *part
  * @param state The name of the state to set 'rel2 relative Y' (not including 
the state value).
  * @param value The state value.
  * @param y The new 'rel2 relative Y' value to set'.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_state_rel2_relative_y_set(Evas_Object *obj, const char 
*part, const char *state, double value, double y);
+EAPI Eina_Bool edje_edit_state_rel2_relative_y_set(Evas_Object *obj, const 
char *part, const char *state, double value, double y);
 
 /** Get the 'rel1 offset X' value of state.
  *
@@ -1344,8 +1352,10 @@ EAPI int edje_edit_state_rel2_offset_y_get(Evas_Object 
*obj, const char *part, c
  * @param state The name of the state to set 'rel1 offset X' (not including 
the state value).
  * @param value The state value.
  * @param x The new 'rel1 offset X' value to set'.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_state_rel1_offset_x_set(Evas_Object *obj, const char 
*part, const char *state, double value, double x);
+EAPI Eina_Bool edje_edit_state_rel1_offset_x_set(Evas_Object *obj, const char 
*part, const char *state, double value, double x);
 
 /** Set the 'rel1 offset Y' value of state.
  *
@@ -1354,8 +1364,10 @@ EAPI void edje_edit_state_rel1_offset_x_set(Evas_Object 
*obj, const char *part,
  * @param state The name of the state to set 'rel1 offset Y' (not including 
the state value).
  * @param value The state value.
  * @param y The new 'rel1 offset Y' valu

[EGIT] [core/efl] master 05/09: edje: make function which change style tag param's (name, value) and delete tag return Eina_Bool.

[m . biliavskyi]

cedric pushed a commit to branch master.

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

commit 6af736860250f1f57c8fdd959495cc6be71b15ad
Author: m.biliavskyi 
Date:   Wed Oct 30 22:04:57 2013 +0900

edje: make function which change style tag param's (name, value) and delete 
tag return Eina_Bool.

This patch make the following function return Eina_Bool so the caller can 
detect errors.
edje_edit_style_tag_value_set
edje_edit_style_tag_name_set
edje_edit_style_tag_del

Reviewers: cedric, seoz

Reviewed By: cedric

CC: reutskiy.v.v, seoz

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Edit.h | 12 +---
 src/lib/edje/edje_edit.c | 31 +--
 2 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 0b1e5c4..47285c6 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -602,8 +602,10 @@ EAPI const char * 
edje_edit_style_tag_value_get(Evas_Object *obj, const char *st
  * @param style Style containing the tag to change.
  * @param tag Name of the tag to set the value for.
  * @param new_value Value for the tag.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_style_tag_value_set(Evas_Object *obj, const char *style, 
const char *tag, const char *new_value);
+EAPI Eina_Bool edje_edit_style_tag_value_set(Evas_Object *obj, const char 
*style, const char *tag, const char *new_value);
 
 /** Set the name of the given tag.
  *
@@ -611,8 +613,10 @@ EAPI void edje_edit_style_tag_value_set(Evas_Object *obj, 
const char *style, con
  * @param style Style containing the tag to rename.
  * @param tag Tag to rename.
  * @param new_name New name for the tag.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_style_tag_name_set(Evas_Object *obj, const char *style, 
const char *tag, const char *new_name);
+EAPI Eina_Bool edje_edit_style_tag_name_set(Evas_Object *obj, const char 
*style, const char *tag, const char *new_name);
 
 /** Add a new tag to the given text style.
  *
@@ -631,8 +635,10 @@ EAPI Eina_Bool edje_edit_style_tag_add(Evas_Object *obj, 
const char *style, cons
  * @param obj Object being edited.
  * @param style Style from where to remove the tag.
  * @param tag Tag to delete.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_style_tag_del(Evas_Object *obj, const char *style, const 
char *tag);
+EAPI Eina_Bool edje_edit_style_tag_del(Evas_Object *obj, const char *style, 
const char *tag);
 
 
 //@}
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index 22d3b6d..dabed3a 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -1645,21 +1645,21 @@ edje_edit_style_tags_list_get(Evas_Object * obj, const 
char* style)
return tags;
 }
 
-EAPI void
+EAPI Eina_Bool
 edje_edit_style_tag_name_set(Evas_Object * obj, const char* style, const char* 
tag, const char*new_name)
 {
Edje_Style_Tag *t;
 
-   GET_ED_OR_RETURN();
-   //printf("SET TAG NAME for '%s' FOR STYLE '%s'\n", tag, style);
+   GET_ED_OR_RETURN(EINA_FALSE);
 
if (!ed->file || !ed->file->styles || !style || !tag)
-  return;
+  return EINA_FALSE;
 
t = _edje_edit_style_tag_get(ed, style, tag);
-   if (!t) return;
+   if (!t) return EINA_FALSE;
_edje_if_string_free(ed, t->key);
t->key = eina_stringshare_add(new_name);
+   return EINA_TRUE;
 }
 
 EAPI const char*
@@ -1680,21 +1680,21 @@ edje_edit_style_tag_value_get(Evas_Object * obj, const 
char* style, const char*
return NULL;
 }
 
-EAPI void
+EAPI Eina_Bool
 edje_edit_style_tag_value_set(Evas_Object * obj, const char* style, const 
char* tag, const char*new_value)
 {
Edje_Style_Tag *t;
 
-   GET_ED_OR_RETURN();
-   //printf("SET TAG VALUE for '%s' FOR STYLE '%s'\n", tag, style);
+   GET_ED_OR_RETURN(EINA_FALSE);
 
-   if (!ed->file || !ed->file->styles || !style || !tag)
-  return;
+   if (!ed->file || !ed->file->styles || !style || !tag || !new_value)
+  return EINA_FALSE;
 
t = _edje_edit_style_tag_get(ed, style, tag);
-   if (!t) return;
+   if (!t) return EINA_FALSE;
_edje_if_string_free(ed, t->value);
t->value = eina_stringshare_add(new_value);
+   return EINA_TRUE;
 }
 
 EAPI Eina_Bool
@@ -1722,17 +1722,19 @@ edje_edit_style_tag_add(Evas_Object * obj, const char* 
style, const char* tag_na
return EINA_TRUE;
 }
 
-EAPI void
+EAPI Eina_Bool
 edje_edit_style_tag_del(Evas_Object * obj, const char* style, const char* tag)
 {
Edje_Style *s;
Edje_Style_Tag *t;
 
-   GET_ED_OR_RETURN();
-   //printf("DEL TAG '%s' IN STYLE '%s'\n", tag, style);
+   GET_ED_OR_RETURN(EINA_FALSE);
+   if (!ed->file || !ed->file->styles || !style || !tag )
+  return EINA_FALSE;
 
s = _edje_edit_style_get(ed, style);
t = _

[EGIT] [core/efl] master 08/09: edje: fix typos/miss merge with a wrong return in edje_edit_image_del.

[Andrii Kroitor]

cedric pushed a commit to branch master.

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

commit cdf7db2fa92121f997309446caa94ec8d23d4ec5
Author: Andrii Kroitor 
Date:   Wed Oct 30 22:19:57 2013 +0900

edje: fix typos/miss merge with a wrong return in edje_edit_image_del.

Because of unconditional return in function, a huge part of its body was
skipped making this function useless. Looked like a typo or missed merge.

Reviewers: cedric, seoz

CC: seoz

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/edje_edit.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index 17e1628..dc62e55 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -4407,8 +4407,6 @@ edje_edit_image_del(Evas_Object *obj, const char* name)
if (!ed->file->image_dir)
   goto invalid_image;
 
- return EINA_TRUE;
-
for (i = 0; i < ed->file->image_dir->entries_count; ++i)
  {
de = ed->file->image_dir->entries + i;

-- 

[EGIT] [core/efl] master 09/09: AUTHORS: we have some new contributor around !

[Cedric Bail]

cedric pushed a commit to branch master.

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

commit a903e80a054b25310dab13522607d43156cb
Author: Cedric Bail 
Date:   Wed Oct 30 22:35:32 2013 +0900

AUTHORS: we have some new contributor around !
---
 AUTHORS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/AUTHORS b/AUTHORS
index 0893f79..b41df9e 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -292,6 +292,9 @@ Daniel Zaoui 
 Daniel Willmann 
 Robert David 
 Bluezery 
+Andrii Kroitor 
+Vorobiov Vitalii 
+m.biliavskyi 
 
 Emotion
 ---

-- 

[EGIT] [core/efl] master 07/09: edje: make function "edje_edit_state_min/max..." return Eina_Bool.

[Vorobiov Vitalii]

cedric pushed a commit to branch master.

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

commit a4e1a2e80ac89ddf75e6b7f4f10f8d2df2c4a7a2
Author: Vorobiov Vitalii 
Date:   Wed Oct 30 22:14:42 2013 +0900

edje: make function "edje_edit_state_min/max..." return Eina_Bool.

Make the following function return Eina_Bool so the caller can detect 
errors :
List of updated functions:
edje_edit_state_min_h_set
edje_edit_state_min_w_set
edje_edit_state_max_h_set
edje_edit_state_max_w_set

Reviewers: cedric, seoz

CC: reutskiy.v.v

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Edit.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 70621be..ca521b5 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -1637,12 +1637,15 @@ EAPI void edje_edit_state_align_y_set(Evas_Object *obj, 
const char *part, const
 EAPI int edje_edit_state_min_w_get(Evas_Object *obj, const char *part, const 
char *state, double value);
 
 /** Set the minimum width value of a part state.
+ * The minimum width should be greater than 0.
  *
  * @param obj Object being edited.
  * @param part Part that contain state.
  * @param state The name of the state to set minimum width (not including the 
state value).
  * @param value The state value.
  * @param min_w Minimum width value.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
 EAPI Eina_Bool edje_edit_state_min_w_set(Evas_Object *obj, const char *part, 
const char *state, double value, int min_w);
 
@@ -1658,12 +1661,15 @@ EAPI Eina_Bool edje_edit_state_min_w_set(Evas_Object 
*obj, const char *part, con
 EAPI int edje_edit_state_min_h_get(Evas_Object *obj, const char *part, const 
char *state, double value);
 
 /** Set the minimum height value of a part state.
+ * The minimum height should be greater than 0.
  *
  * @param obj Object being edited.
  * @param part Part that contain state.
  * @param state The name of the state to set minimum height (not including the 
state value).
  * @param value The state value.
  * @param min_h Minimum height value.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
 EAPI Eina_Bool edje_edit_state_min_h_set(Evas_Object *obj, const char *part, 
const char *state, double value, int min_h);
 
@@ -1679,12 +1685,17 @@ EAPI Eina_Bool edje_edit_state_min_h_set(Evas_Object 
*obj, const char *part, con
 EAPI int edje_edit_state_max_w_get(Evas_Object *obj, const char *part, const 
char *state, double value);
 
 /** Set the maximum width value of a part state.
+ * The maximum width should be greater than -1.
+ * The value -1 means that state doesn't have any boundaries on width 
direction.
+ * (it can be any size that is bigger than it's min)
  *
  * @param obj Object being edited.
  * @param part Part that contain state.
  * @param state The name of the state to set maximum width (not including the 
state value).
  * @param value The state value.
  * @param max_w Maximum width value.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
 EAPI Eina_Bool edje_edit_state_max_w_set(Evas_Object *obj, const char *part, 
const char *state, double value, int max_w);
 
@@ -1700,12 +1711,17 @@ EAPI Eina_Bool edje_edit_state_max_w_set(Evas_Object 
*obj, const char *part, con
 EAPI int edje_edit_state_max_h_get(Evas_Object *obj, const char *part, const 
char *state, double value);
 
 /** Set the maximum height value of a part state.
+ * The maximum height should be greater than -1.
+ * The value -1 means that state doesn't have any boundaries on height 
direction.
+ * (it can be any size that is bigger than it's min)
  *
  * @param obj Object being edited.
  * @param part Part that contain state.
  * @param state The name of the state to set maximum height (not including the 
state value).
  * @param value The state value.
  * @param max_h Maximum height value.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
 EAPI Eina_Bool edje_edit_state_max_h_set(Evas_Object *obj, const char *part, 
const char *state, double value, int max_h);
 

-- 

[EGIT] [core/efl] master 04/09: edje: make setters for "edje_edit_state_image_..." return Eina_Bool.

[Vorobiov Vitalii]

cedric pushed a commit to branch master.

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

commit dae7b7349ecf79a41b0e89edc5e501b690119da4
Author: Vorobiov Vitalii 
Date:   Wed Oct 30 22:00:11 2013 +0900

edje: make setters for "edje_edit_state_image_..." return Eina_Bool.

This patch make the following function return Eina_Bool so the caller can
detect errors.
edje_edit_state_image_set
edje_edit_state_image_border_set
edje_edit_state_image_border_fill_set

Reviewers: cedric, seoz

CC: reutskiy.v.v

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Edit.h | 24 +--
 src/lib/edje/edje_edit.c | 60 +---
 2 files changed, 54 insertions(+), 30 deletions(-)

diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 31ec1a9..0b1e5c4 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -2598,8 +2598,10 @@ EAPI const char * edje_edit_state_image_get(Evas_Object 
*obj, const char *part,
  * @param state The name of the state to set the image that will be used (not 
including the state value).
  * @param value The state value.
  * @param image The name of the image (must be an image contained in the edje 
file).
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE - otherwise.
  */
-EAPI void edje_edit_state_image_set(Evas_Object *obj, const char *part, const 
char *state, double value, const char *image);
+EAPI Eina_Bool edje_edit_state_image_set(Evas_Object *obj, const char *part, 
const char *state, double value, const char *image);
 
 /** Get image id for a given image name.
  *
@@ -2659,33 +2661,41 @@ EAPI void edje_edit_state_image_border_get(Evas_Object 
*obj, const char *part, c
  * @param r Right border value (or -1).
  * @param t Top border value (or -1).
  * @param b Bottom border value (or -1).
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE - otherwise.
  */
-EAPI void edje_edit_state_image_border_set(Evas_Object *obj, const char *part, 
const char *state, double value, int l, int r, int t, int b);
+EAPI Eina_Bool edje_edit_state_image_border_set(Evas_Object *obj, const char 
*part, const char *state, double value, int l, int r, int t, int b);
 
 /** Get if the image center should be draw.
  *
- * 1 means to draw the center, 0 to don't draw it.
+ * 1 or 2 means to draw the center, 0 to don't draw it.
+ * If 1 - then the center will apply alpha channel.
+ * If 2 (SOLID mode) - then the center of an image wont have alpha channel 
(Just black color).
  *
  * @param obj Object being edited.
  * @param part Part that contain state.
  * @param state The name of the state to get the image border fill (not 
including the state value).
  * @param value The state value.
  *
- * @return 1 if the center of the bordered image is draw, 0 otherwise.
+ * @return 2 if the center of the bordered image is draw without alpha, 1 
dawing with alpha and 0 not drawing the center.
  */
 EAPI unsigned char edje_edit_state_image_border_fill_get(Evas_Object *obj, 
const char *part, const char *state, double value);
 
 /** Set if the image center should be draw.
  *
- * 1 means to draw the center, 0 to don't draw it.
+ * 1 or 2 means to draw the center, 0 to don't draw it.
+ * If 1 - then the center will apply alpha channel.
+ * If 2 (SOLID mode) - then the center of an image wont have alpha channel 
(Just black color).
  *
  * @param obj Object being edited.
  * @param part Part that contain state.
  * @param state The name of the state to set the image border fill (not 
including the state value).
  * @param value The state value.
- * @param fill Fill to be se. 1 if the center of the bordered image is draw, 0 
otherwise.
+ * @param fill Fill to be set. 1 or 2 if the center of the bordered image is 
draw, 0 otherwise.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE - otherwise.
  */
-EAPI void edje_edit_state_image_border_fill_set(Evas_Object *obj, const char 
*part, const char *state, double value, unsigned char fill);
+EAPI Eina_Bool edje_edit_state_image_border_fill_set(Evas_Object *obj, const 
char *part, const char *state, double value, unsigned char fill);
 
 /** Get the list of all the tweens images in the given part state.
  *
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index 384f97e..22d3b6d 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -4581,27 +4581,30 @@ edje_edit_state_image_get(Evas_Object *obj, const char 
*part, const char *state,
return eina_stringshare_add(image);
 }
 
-EAPI void
+EAPI Eina_Bool
 edje_edit_state_image_set(Evas_Object *obj, const char *part, const char 
*state, double value, const char *image)
 {
Edje_Part_Description_Image *img;
int id;
 
-   GET_PD_OR_RETURN();
+   if ((!obj) || (!part) || (!state) || (!image))
+ return EINA_FALSE;
 
-   if (!image) return;
+   eina_error_se

[EGIT] [core/efl] master 06/09: edje: make edje_edit_group_*_*_set return Eina_Bool.

[Andrii Kroitor]

cedric pushed a commit to branch master.

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

commit 919c51de088fb7a3e352e467caf774b20fceb70a
Author: Andrii Kroitor 
Date:   Wed Oct 30 22:11:22 2013 +0900

edje: make edje_edit_group_*_*_set return Eina_Bool.

Make the following function return Eina_Bool so that the caller can detect 
errors :
edje_edit_group_min_w_set
edje_edit_group_min_h_set
edje_edit_group_max_w_set
edje_edit_group_max_h_set

Reviewers: cedric, seoz

CC: reutskiy.v.v

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Edit.h | 16 
 src/lib/edje/edje_edit.c | 29 -
 2 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 47285c6..70621be 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -271,8 +271,10 @@ EAPI int edje_edit_group_min_w_get(Evas_Object *obj);
  *
  * @param obj Object being edited.
  * @param w New minimum width for the group.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_group_min_w_set(Evas_Object *obj, int w);
+EAPI Eina_Bool edje_edit_group_min_w_set(Evas_Object *obj, int w);
 
 /** Get the group minimum height.
  *
@@ -286,8 +288,10 @@ EAPI int edje_edit_group_min_h_get(Evas_Object *obj);
  *
  * @param obj Object being edited.
  * @param h New minimum height for the group.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_group_min_h_set(Evas_Object *obj, int h);
+EAPI Eina_Bool edje_edit_group_min_h_set(Evas_Object *obj, int h);
 
 /** Get the group maximum width.
  *
@@ -301,8 +305,10 @@ EAPI int edje_edit_group_max_w_get(Evas_Object *obj);
  *
  * @param obj Object being edited.
  * @param w New maximum width for the group.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_group_max_w_set(Evas_Object *obj, int w);
+EAPI Eina_Bool edje_edit_group_max_w_set(Evas_Object *obj, int w);
 
 /** Get the group maximum height.
  *
@@ -316,8 +322,10 @@ EAPI int edje_edit_group_max_h_get(Evas_Object *obj);
  *
  * @param obj Object being edited.
  * @param h New maximum height for the group.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
  */
-EAPI void edje_edit_group_max_h_set(Evas_Object *obj, int h);
+EAPI Eina_Bool edje_edit_group_max_h_set(Evas_Object *obj, int h);
 
 
 //@}
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index dabed3a..17e1628 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -1115,19 +1115,22 @@ edje_edit_group_name_set(Evas_Object *obj, const char 
*new_name)
return EINA_TRUE;
 }
 
-#define FUNC_GROUP_ACCESSOR(Class, Value)  \
-  EAPI int \
-  edje_edit_group_##Class##_##Value##_get(Evas_Object *obj)\
-  {\
- GET_ED_OR_RETURN(-1); \
- if (!ed->collection) return -1;   \
- return ed->collection->prop.Class.Value;  \
-  }\
-  EAPI void\
-  edje_edit_group_##Class##_##Value##_set(Evas_Object *obj, int v) \
-  {\
- GET_ED_OR_RETURN();   \
- ed->collection->prop.Class.Value = v; \
+#define FUNC_GROUP_ACCESSOR(Class, Value) \
+  EAPI int \
+  edje_edit_group_##Class##_##Value##_get(Evas_Object *obj) \
+  { \
+ GET_ED_OR_RETURN(-1); \
+ if (!ed->collection) return -1; \
+ return ed->collection->prop.Class.Value; \
+  } \
+  EAPI Eina_Bool \
+  edje_edit_group_##Class##_##Value##_set(Evas_Object *obj, int v) \
+  { \
+ GET_ED_OR_RETURN(EINA_FALSE); \
+ if (!ed->collection) return EINA_FALSE; \
+ if (v < 0) return EINA_FALSE; \
+ ed->collection->prop.Class.Value = v; \
+ return EINA_TRUE; \
   }
 
 FUNC_GROUP_ACCESSOR(min, w);

-- 

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[Vinícius dos Santos Oliveira]

Em Qua, 2013-10-30 às 22:42 +0900, Carsten Haitzler escreveu:

> given what you want is still a menu you can re-use the existing edje
> groups/parts for now until you have wrapped your head around edje.
> trust me -
> it's not something a document will tell you or teach you. it's cold
> hard slog
> and experience that will. :)


Rasterman,

I don't want to start a flame war or something, but maybe you're used to
shitty java documentation and this is the reason why you underestimate
documentation so much, but documentation is useful. This is an example
of a good documentation:
http://qt-project.org/doc/qt-5.0/qtgui/qpainter.html#details


-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker


signature.asc
Description: This is a digitally signed message part
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[The Rasterman]

On Wed, 30 Oct 2013 11:55:31 -0300 Vinícius dos Santos Oliveira
 said:

> Em Qua, 2013-10-30 às 22:42 +0900, Carsten Haitzler escreveu:
> 
> > given what you want is still a menu you can re-use the existing edje
> > groups/parts for now until you have wrapped your head around edje.
> > trust me -
> > it's not something a document will tell you or teach you. it's cold
> > hard slog
> > and experience that will. :)
> 
> 
> Rasterman,
> 
> I don't want to start a flame war or something, but maybe you're used to
> shitty java documentation and this is the reason why you underestimate
> documentation so much, but documentation is useful. This is an example
> of a good documentation:
> http://qt-project.org/doc/qt-5.0/qtgui/qpainter.html#details

no.. i'm not used to java documentation. i swore off java back in 1995 or so...
and do not want to ever go near it again.

this is simply a matter of time. spend 1hr adding a feature someone wants, or 1
hr writing docs. i personally use docs as reference only - i ALWAYS use example
codee. nothing to do with java - it simply is faster, easier and more
practical. i read unix man pages to begin with and frankly they told me very
little at all. a whole tonne of words for very little use. examples taught me
100x more in the same amount of effort with docs backing it up as reference.

as such most of efl does have docs. they are not voluminous essays. again - a
matter of time. if you wish to contribute by writing voluminous docs.. go for
it. :)

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


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[Vinícius dos Santos Oliveira]

Em Qui, 2013-10-31 às 00:48 +0900, Carsten Haitzler escreveu:

> this is simply a matter of time. spend 1hr adding a feature someone
> wants, or 1
> hr writing docs.


Documentation is a feature too.


> i personally use docs as reference only - i ALWAYS use example
> codee. nothing to do with java - it simply is faster, easier and more
> practical.


Documentation can include snippets.


> i read unix man pages to begin with and frankly they told me very
> little at all. a whole tonne of words for very little use. examples
> taught me
> 100x more in the same amount of effort with docs backing it up as
> reference.


Comparing manpages with HTML rich (or even PDFs) docs.


  * Manpages cannot have images (maybe with Terminology this is no
longer true) and for a GUI toolkit this is kind of a must.
  * Manpages don't have an easily browsable content (like HTML) have

  * Summary
  * Detailed description and extra sections
  * Extra pages (not directly related to one class only)
  * A small text for each function



> as such most of efl does have docs. they are not voluminous essays.
> again - a
> matter of time. if you wish to contribute by writing voluminous docs..
> go for
> it. :)


The magic of open source. :)


-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker


signature.asc
Description: This is a digitally signed message part
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/01: Ecore_Common.h: fixed documentations.

[Daniel Juyung Seo]

seoz pushed a commit to branch master.

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

commit 2a1d175c0287a8a2adbf1e67d42337a068c4a01a
Author: Daniel Juyung Seo 
Date:   Thu Oct 31 01:04:24 2013 +0900

Ecore_Common.h: fixed documentations.
---
 src/lib/ecore/Ecore_Common.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/lib/ecore/Ecore_Common.h b/src/lib/ecore/Ecore_Common.h
index 98279a7..83307f2 100644
--- a/src/lib/ecore/Ecore_Common.h
+++ b/src/lib/ecore/Ecore_Common.h
@@ -2007,12 +2007,12 @@ EAPI double ecore_animator_pos_map(double pos, 
Ecore_Pos_Map map, double v1, dou
  * set a custom tick source by setting the source to
  * ECORE_ANIMATOR_SOURCE_CUSTOM and then drive it yourself based on some input
  * tick source (like another application via ipc, some vertical blanking
- * interrupt interrupt etc.) using
- *ecore_animator_custom_source_tick_begin_callback_set() and
- *ecore_animator_custom_source_tick_end_callback_set() to set the functions
+ * interrupt, and etc.) using
+ * ecore_animator_custom_source_tick_begin_callback_set() and
+ * ecore_animator_custom_source_tick_end_callback_set() to set the functions
  * that will be called to start and stop the ticking source, which when it
- * gets a "tick" should call ecore_animator_custom_tick() to make the "tick" 
over 1
- * frame.
+ * gets a "tick" should call ecore_animator_custom_tick() to make the "tick"
+ * over 1 frame.
  */
 EAPI void ecore_animator_source_set(Ecore_Animator_Source source);
 /**
@@ -2034,7 +2034,7 @@ EAPI Ecore_Animator_Source 
ecore_animator_source_get(void);
  * The Ecore Animator infrastructure handles tracking if animators are needed
  * or not and which ones need to be called and when, but when the tick source
  * is custom, you have to provide a tick source by calling
- *ecore_animator_custom_tick() to indicate a frame tick happened. In order
+ * ecore_animator_custom_tick() to indicate a frame tick happened. In order
  * to allow the source of ticks to be dynamically enabled or disabled as
  * needed, the @p func when set is called to enable the tick source to
  * produce tick events that call ecore_animator_custom_tick(). If @p func

-- 

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[Robert Heller]

At Wed, 30 Oct 2013 12:09:52 -0400 Enlightenment users discussion & support 
 wrote:

> 
> Hi,
> 
> Just to chime in with 10c's worth.
> 
> This is my personal preference, working examples atleast as a base works
> for me ( examples as in code )...  Documentaions words are ok for the nitty
> gritty but not as a substitute for a good example.
> 
> If you look at most tech books, the question is how many of us read any of
> them cover to cover?.

But *I* do find them *very* useful, even if I don't read them cover to cover.  
Often reading a page here or there (or even a whole section) if *very* useful, 
and *not* because of the included examples.  And an *important* part of any 
tech book is its index and/or table of contents -- either/both of these gets 
me to the page or section I need to read.

> 
> Probably near none at all, so really for me thats enough said.
>

The main problem with documentation-by-example is what happens when there
isn't an example that covers the question at hand? Or (worse) when the
example's name or title does not fully suggest or explain what it is an
example of. Also, sometimes it is critical when looking at examples that there
is some explaination of the concepts involved. Examples alone can never really
explain how to do things, if the *underlying* concepts are not either known or
else explained. For example, what does 'swallow' mean in the context of edje?
The code in e_menu is using this, but I have no clue as to what is going on
and the swallow example does not really *explain* what is going on, it just
shows you how to use it, without explaining why you would do it or what 
its purpose is. Somehow, I don't think it has anything to do with eating or 
birds (but maybe it does?).

 
> Nige
> 
> Disclaimer: This is my personal belief as stated.
> 
> 
> On Wed, Oct 30, 2013 at 11:58 AM, Vinícius dos Santos Oliveira <
> vini.ipsma...@gmail.com> wrote:
> 
> > Em Qui, 2013-10-31 às 00:48 +0900, Carsten Haitzler escreveu:
> >
> > > this is simply a matter of time. spend 1hr adding a feature someone
> > > wants, or 1
> > > hr writing docs.
> >
> >
> > Documentation is a feature too.
> >
> >
> > > i personally use docs as reference only - i ALWAYS use example
> > > codee. nothing to do with java - it simply is faster, easier and more
> > > practical.
> >
> >
> > Documentation can include snippets.
> >
> >
> > > i read unix man pages to begin with and frankly they told me very
> > > little at all. a whole tonne of words for very little use. examples
> > > taught me
> > > 100x more in the same amount of effort with docs backing it up as
> > > reference.
> >
> >
> > Comparing manpages with HTML rich (or even PDFs) docs.
> >
> >
> >   * Manpages cannot have images (maybe with Terminology this is no
> > longer true) and for a GUI toolkit this is kind of a must.
> >   * Manpages don't have an easily browsable content (like HTML) have
> >
> >   * Summary
> >   * Detailed description and extra sections
> >   * Extra pages (not directly related to one class only)
> >   * A small text for each function
> >
> >
> >
> > > as such most of efl does have docs. they are not voluminous essays.
> > > again - a
> > > matter of time. if you wish to contribute by writing voluminous docs..
> > > go for
> > > it. :)
> >
> >
> > The magic of open source. :)
> >
> >
> > --
> > Vinícius dos Santos Oliveira
> > https://about.me/vinipsmaker
> >
> >
> > --
> > Android is increasing in popularity, but the open development platform that
> > developers love is also attractive to malware creators. Download this white
> > paper to learn more about secure code signing practices that can help keep
> > Android apps secure.
> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-users mailing list
> > enlightenment-us...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> >
> >
> 
> 

-- 
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


 

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[Robert Heller]

At Wed, 30 Oct 2013 13:43:45 -0400 Enlightenment users discussion & support 
 wrote:

> 
> On Wed, Oct 30, 2013 at 1:02 PM, Robert Heller  wrote:
> 
> > At Wed, 30 Oct 2013 12:09:52 -0400 Enlightenment users discussion &
> > support  wrote:
> >
> > >
> > > Hi,
> > >
> > > Just to chime in with 10c's worth.
> > >
> > > This is my personal preference, working examples atleast as a base works
> > > for me ( examples as in code )...  Documentaions words are ok for the
> > nitty
> > > gritty but not as a substitute for a good example.
> > >
> > > If you look at most tech books, the question is how many of us read any
> > of
> > > them cover to cover?.
> >
> >   But *I* do find them *very* useful, even if I don't read them cover to
> > cover.
> >   Often reading a page here or there (or even a whole section) if *very*
> > useful,
> >   and *not* because of the included examples.  And an *important* part of
> > any
> >   tech book is its index and/or table of contents -- either/both of these
> > gets
> >   me to the page or section I need to read.
> >
> 
> 
> Fair comment,
> 
> 
> 
> >
> > >
> > > Probably near none at all, so really for me thats enough said.
> > >
> >
> > The main problem with documentation-by-example is what happens when there
> > isn't an example that covers the question at hand? Or (worse) when the
> > example's name or title does not fully suggest or explain what it is an
> > example of. Also, sometimes it is critical when looking at examples that
> > there
> > is some explaination of the concepts involved. Examples alone can never
> > really
> > explain how to do things, if the *underlying* concepts are not either
> > known or
> > else explained. For example, what does 'swallow' mean in the context of
> > edje?
> > The code in e_menu is using this, but I have no clue as to what is going on
> > and the swallow example does not really *explain* what is going on, it just
> > shows you how to use it, without explaining why you would do it or what
> > its purpose is. Somehow, I don't think it has anything to do with eating or
> > birds (but maybe it does?).
> >
> >
> I think at this stage, perhaps it would be good to take the opportunity to
> take a look at the documentation available.

I have, and it is not *useful* -- there isn't any explaination of what is
really going on. The 'Swallow Example' does not really explain what
"edje_object_part_swallow(edje_obj, "part_one", rect);" does. There does not
seem to be a *useful* explaination of what edje_object_part_swallow() does,
why you should use it (or not). It is there in the code I copied from
e_menu.c, but I have no clue whether or not it is or is the reason I am not
seeing anything useful on the screen. Or if I need to add something to the
.edc file or what I should add to the .edc file.

Bascially, *none* of the edje_* *C* functions are explained in any detail, the 
examples, just show their use, within the context of the given examples, but 
without the explaination needed to extrapolate to other contexts.

Maybe the problem is that *I* have not absorbed the 'culture' behind the E17 
project.  I have not worked with a *C* based GUI API in some time (the last C 
based GUI API I worked with was Motif).  Most of the GUI programming I have 
been doing for the past 20+ years has been with Tcl/Tk.  (I have been coding 
in C and C++ all though that time, but the C code has not been GUI coding -- 
the C and C++ code ends up as a loadable shared library loaded into a Tcl/Tk 
main program that implements the GUI, if any.)

> 
> Alot of these comments though have been made on howto's,  in that they
> usually only made sense after you have completed the task yourself.

I am not sure that this really makes sense for anything other then rote tasks.
And then one may end up only learning the rote task without the understanding
how to extend the task to other contexts. That is one can learn that to count
to 10 in C one does:

   int i;
   for (i=1, i<=10; i++) printf("%d\n",i);
   
but without additional information it is not clear how to count backwards or
to only count even numbers (the above code does not explain how to do either
of these things). One cannot fully learn how to generally write C programs
from random little examples like the above. A proper reference book for the C
language *has* have more in it besides a dozzen or so examples like the above.
Otherwise it is not really useful.

> 
> I would not doubt that the current documents could use some work.  I am not
> actually 100% on whom would be doing the task.  Possibly the person who
> wrote / contributed to the module in question.
> 
> Would be cool to find a common agreement here.
> 
> Nige
> 
> 
> >
> > > Nige
> > >
> > > Disclaimer: This is my personal belief as stated.
> > >
> > >
> > > On Wed, Oct 30, 2013 at 11:58 AM, Vinícius dos Santos Oliveira <
> > > vini.ipsma...@gmail.com> wrote:
> > >
> > > > Em Qui, 2013-10-31 às 00:48 +0900, Carsten Haitzler escreveu:
> > > >
> > > > 

[EGIT] [bindings/python/python-efl] master 01/01: Edje-edit: Disable build and tests.

[Kai Huuhko]

kuuko pushed a commit to branch master.

http://git.enlightenment.org/bindings/python/python-efl.git/commit/?id=e4e56b260547060582449a35d06a761b15cb0810

commit e4e56b260547060582449a35d06a761b15cb0810
Author: Kai Huuhko 
Date:   Wed Oct 30 19:56:40 2013 +0200

Edje-edit: Disable build and tests.

Do this for now as it's undergoing changes and mostly broken anyway.
---
 setup.py | 12 ++--
 tests/edje/{test_04_edit.py => disabled_test_04_edit.py} |  0
 tests/edje/test_05_decorators.py |  1 +
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/setup.py b/setup.py
index 302af23..07ee857 100755
--- a/setup.py
+++ b/setup.py
@@ -128,12 +128,12 @@ if set(("build", "build_ext", "install", "bdist", 
"sdist")) & set(sys.argv):
 modules.append(edje_ext)
 
 # Edje_Edit
-edje_edit_ext = Extension("edje_edit", 
["efl/edje/efl.edje_edit"+module_suffix],
-define_macros = 
[('EDJE_EDIT_IS_UNSTABLE_AND_I_KNOW_ABOUT_IT', None)],
-include_dirs = ['include/'],
-extra_compile_args = edje_cflags,
-extra_link_args = edje_libs + eina_libs + 
evas_libs)
-modules.append(edje_edit_ext)
+# edje_edit_ext = Extension("edje_edit", 
["efl/edje/efl.edje_edit"+module_suffix],
+# define_macros = 
[('EDJE_EDIT_IS_UNSTABLE_AND_I_KNOW_ABOUT_IT', None)],
+# include_dirs = ['include/'],
+# extra_compile_args = edje_cflags,
+# extra_link_args = edje_libs + eina_libs + 
evas_libs)
+# modules.append(edje_edit_ext)
 
 # Emotion
 emotion_cflags, emotion_libs = pkg_config('Emotion', 'emotion', "1.7.99")
diff --git a/tests/edje/test_04_edit.py b/tests/edje/disabled_test_04_edit.py
similarity index 100%
rename from tests/edje/test_04_edit.py
rename to tests/edje/disabled_test_04_edit.py
diff --git a/tests/edje/test_05_decorators.py b/tests/edje/test_05_decorators.py
index 333dcfd..1ccc051 100644
--- a/tests/edje/test_05_decorators.py
+++ b/tests/edje/test_05_decorators.py
@@ -43,6 +43,7 @@ class MyEdje(Edje):
 expected_text_parts.remove(part)
 
 
+@unittest.expectedFailure # TODO XXX "zoom,stop" remains
 class TestEdjeDecoratedCallbacks(unittest.TestCase):
 def setUp(self):
 self.canvas = evas.Canvas(method="buffer",

-- 

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[Vinícius dos Santos Oliveira]

Em Qua, 2013-10-30 às 13:43 -0400, Nigel Sollars escreveu:

> Would be cool to find a common agreement here.
> 
> Nige


Like Rasterman said: It's an open source project. We can change the
project and if the contribution is useful, it'll go upstream.

But about "common agreement". This is not needed, because the options
don't exclude each other. We can have documentation AND examples.


-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker


signature.asc
Description: This is a digitally signed message part
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Monitor/output parameter for fullscreen

[Rafael Antognolli]

On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
 wrote:
> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli  
> wrote:
>> Hey everyone,
>>
>> Our current API for setting a window as fullscreen does not support
>> specifying which output/display/monitor should be used as fullscreen.
>> However, wayland does support it.
>>
>> Would it make sense to have such parameter in the fullscreen_set API?
>> Or should it be a wayland-only API?
>
> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
> NULL = unset */
>
> the current version remains and sets on current display. Alternatively
> we could just move the window to another display before making that
> fullscreen, no idea if this is okay.

Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.

>> For the latter case, how would we do that? Maybe exposing an API that
>> allows to set the "preferred" output, and then when fullscreen_set is
>> called, it just uses that one?
>
> I'd say we need to make this in one go, unless we want some kind of
> general assignment to one display (not just for FS mode).

OK...

>
>> There's also a need to specify how the output should be referred to.
>> Using an (unsigned) int, where 0 is the first output, 1 is the second,
>> etc? Or maybe allowing to specify something like "always the biggest
>> one in area", or the widest one, or whatever... any thoughts?
>
> We'd need a way to enumerate the displays (or whatever we call them,
> like zone, etc), they should return their properties such as size,
> position (?), capabilities (3d/stereo? color? what do we have here?)
> and some string to make it easy to debug.
>
> we have the handle to it, so it can be windowsystem agnostic
> (Display_ID *, which can be implemented differently for windows, x11,
> wayland...)

So you are proposing that we change a good portion of our API to be
aware of multiple displays?

>
>> That reminds me that we still have another problem. APIs such
>> ecore_wl_screen_size_get() return only the screen size of the first
>> monitor, not both.
>
> same as above, this should be based on current window (if there is a
> window handle) or the first one (if there is not, alterntively we can
> state it will refer to screen the mouse is over, but I guess this is
> incorrect and makes everything less predictable).

Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).

>> What about a common API to select which output we are talking about,
>> that must be called before any call that would refer to a specific
>> output? The problem with this is that it would make code very
>> wayland-specific :-/
>
> how so? just use the opaque handlers and abstract stuff in there.

OK, so you suggestion is something like:

Display {
  ID;
  size;
  position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
  capabilities (3d/stereo? color?)
  dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}

And then change/add some APIs to refer to a specific display when
setting things?

> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (19) 9225-2202
> Contact: http://www.gustavobarbieri.com.br/contact
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Rafael Antognolli

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[Robert Heller]

At Wed, 30 Oct 2013 16:42:14 -0300 Enlightenment users discussion & support  
 wrote:

> 
> 
> 
> Em Qua, 2013-10-30 às 13:43 -0400, Nigel Sollars escreveu:
> 
> > Would be cool to find a common agreement here.
> > 
> > Nige
> 
> 
> Like Rasterman said: It's an open source project. We can change the
> project and if the contribution is useful, it'll go upstream.
> 
> But about "common agreement". This is not needed, because the options
> don't exclude each other. We can have documentation AND examples.

YES+++

> 
> 

-- 
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments



  

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [misc/entrance] master 01/01: entrance: many improvment * improve pam login * fix some profile mistake when login an user * use EINA_UNUSED * code refactoring * remove session log

[Guillaume Friloux]

Hello guys, i dont put quotes as there would be too many things to quote 
and i want my mail to be short.

Entrance is used by a bunch(maybe i should define 'bunch') of peoples, 
already using this git repo.
The fact that yoz is the only active dev on it ATM doesnt makes it a 
personnal project. A project is defined "personnal" when there is only 
one user, not one dev.
In my opinion, this project has enough users to be in /misc/ or /apps/, 
and not be isolated in /devs/ repo (or start to also move ecrire, 
ephoto, etc). It is also a very interesting project that needs audience, 
hidding it in /devs/ is BAD.

You guys are asking rules to be respected on a project you dont even own 
(leading to "lets put this out of repos").
If his patches bothers you, while you are not even working on it, you 
can configure your mail client to filter those commits and mark them as 
read instead of making changes that would affect michael and all the 
entrance users.

Michael already does atomic commits on all the /efl/ patches he does, so 
he doesnt have to be told about that.
If you join his project and start working on it, then im pretty sure he 
will start to do a lot of nice things for you, even explaining his code 
and answering every question.

Re-reading my mail, it can seem rude, but its not, its just 'clear'.

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/01: fix raster's typo

[Jérémy Zurcher]

jeyzu pushed a commit to branch master.

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

commit 1eb85fe7468d5847624e430c755b440ffa43e510
Author: Jérémy Zurcher 
Date:   Wed Oct 30 22:41:13 2013 +0100

fix raster's typo
---
 src/lib/eina/eina_share_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/eina/eina_share_common.c b/src/lib/eina/eina_share_common.c
index 563289e..0907ea1 100644
--- a/src/lib/eina/eina_share_common.c
+++ b/src/lib/eina/eina_share_common.c
@@ -272,7 +272,7 @@ void
 eina_share_common_population_del(Eina_Share *share, int slen)
 {
eina_spinlock_take(&_mutex_big);
-   eina_share_common_population_nolock_del(chare, slen);
+   eina_share_common_population_nolock_del(share, slen);
eina_spinlock_release(&_mutex_big);
 }
 

-- 

Re: [E-devel] Is there *real* documentation for edje?

[Jérémy Zurcher]

Hi all,

lot's of words in that thread, I'll add my practical one

you can do it all without edje,
but it is a nice way to separate the gui from the application logic.

using edje + edje_player also allows you to easily test you layout,
using bg colors maybe to differenciate the parts,
and send signals to your edj to test your edje programms.
have a look at this nice blog page :
http://brunodilly.org/blog/debugging-edje-themes-edc-edje-player/

if you wonder about swallows, look ie. at the popup widget edc and doc

http://git.enlightenment.org/core/elementary.git/tree/data/themes/edc/elm/popup.edc
(heavy I concede )
http://docs.enlightenment.org/stable/elementary/group__Popup.html

it defines parts of type SWALLOW, so that you can:
build your content with elm/evas and swallow it in the default part using:
elm_object_content_set(popup, my_object);
or swallow an object in a specific part:
elm_object_part_content_set(popup, "button3", btn);
or set a text:
elm_object_part_text_set(popup, "title,text", "Error");
or disable an part:
part = edje_object_part_object_get(edj, "button3");
elm_object_disabled_set(part, disabled);
same using signals:
part = edje_object_part_object_get(edj, "button3");
elm_object_signal_emit(btn, "elm,state,disabled", "elm");

or you can build a content using edc files, load it using:
layout = elm_layout_add(parent_object);
elm_layout_file_set(layout, edje_file_path, group_name);

then swallow it in another swallow part of another layout/widget.
using the technics above.

these are mainly elementary based examples,
it's basicaly enhanced wrappers around edje/evas functions.

you'll find a lot of good stuff in
http://git.enlightenment.org/devs/seoz/samples.git/tree/
or a single one in my WIP app skeleton
http://git.enlightenment.org/devs/jeyzu/skeletons.git/tree/elm-skel

don't forget about clouseau too
http://git.enlightenment.org/tools/clouseau.git/tree/README

hope it clarifies a little bit and shows you that material exists
and does help you.

--- Hell'O from Yverdoom

Jérémy (jeyzu)

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [misc/entrance] master 01/01: entrance: many improvment * improve pam login * fix some profile mistake when login an user * use EINA_UNUSED * code refactoring * remove session log

[Michaël Bouchaud]

I will try to find my best words.
Sorry to annoy you with a huge commit. But as I say before, I'm the main
dev of entrance and the only one to take care about it. And I do it in my
free times, as my contribution to the efl libraries and enlightenment since
a long time.
Raster or cedric have made some contribution to entrance before. But it was
a long time ago. The last diff I see, from another than me, is from raster,
where is a diff is on a pam file (not C code). Raster don't see I provide a
file for debian-ubuntu pam...
So I take this into account that an advanced user, who don't notice I
provide this one. So I change my mind and today, I provide a debian pam
file in first. (the second pam file is for gentoo or arch. Where I think
user are welcome and get used to do some patch or custom cp for things to
work, instead of ubuntu users...).
But this is not the problem here. I just want you point out, I have some
users who use entrance everyday and welcome to have the last revision to
test it. We have migrated from svn to git. OK. They do it, and since I
still have about 10 mails each months for entrance...
Now I have 4 choices.
- First one, try to do atomic commit to pleased you and have some review
from nobody...(maybe cedric for some commit not all, where he will say
nothing...). As I said before, I don't want to spare my time for that.
- Second choice, don't do atomic commit... and nobody can (want) review me.
But I will annoy some people with my huge commit (where this people can
configure mailing box to ignore it as said by kuri).
- Third choice, as second choice don't do atomic commit, but my project go
in my dev dir. Here my user will be annoyed, because he don't be noticed by
recent changes and I lose my futur audience ...
- Fourth choice, don't do atomic commit... and open my own github. And I
will annoy my user for a last time and don't boring you again.

But in last, if the last choice comes to be the best one. I will be very
sad to go away from this repositories, because I think entrance could be a
good publicity. Further, entrance works like a charm for years, and I try
to not b0rk it...

In last, but I can't say "ok, I go to my own dev dir and don't boring you
again" here. But I understand your point of view. So, I let you assume your
remarks and futur decision. I'm not the one who have coded 90% percent of
code of efl libs so I can't be a dictator to make some decision. I just
want to have some arrangement with you on this point.

PS: I never be remunerated for my contribution to efl libs or elementary,
if I have succesfully imposed the efl and enlightenment in my last jobs. I
always do my dev on the efl libraries on my free time as I do for entrance.
If I had never considered to improve or debugging efl libraries and
elementary, surely entrance would be in a better state today. And
elementary in a worse state... as the efl libraries. Please take this into
accounts.

Regards


2013/10/30 Guillaume Friloux 

> Hello guys, i dont put quotes as there would be too many things to quote
> and i want my mail to be short.
>
> Entrance is used by a bunch(maybe i should define 'bunch') of peoples,
> already using this git repo.
> The fact that yoz is the only active dev on it ATM doesnt makes it a
> personnal project. A project is defined "personnal" when there is only
> one user, not one dev.
> In my opinion, this project has enough users to be in /misc/ or /apps/,
> and not be isolated in /devs/ repo (or start to also move ecrire,
> ephoto, etc). It is also a very interesting project that needs audience,
> hidding it in /devs/ is BAD.
>
> You guys are asking rules to be respected on a project you dont even own
> (leading to "lets put this out of repos").
> If his patches bothers you, while you are not even working on it, you
> can configure your mail client to filter those commits and mark them as
> read instead of making changes that would affect michael and all the
> entrance users.
>
> Michael already does atomic commits on all the /efl/ patches he does, so
> he doesnt have to be told about that.
> If you join his project and start working on it, then im pretty sure he
> will start to do a lot of nice things for you, even explaining his code
> and answering every question.
>
> Re-reading my mail, it can seem rude, but its not, its just 'clear'.
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Michaël Bouchaud (yoz) 
-

[EGIT] [misc/entrance] master 01/01: entrance: missing an author

[Michael Bouchaud]

yoz pushed a commit to branch master.

http://git.enlightenment.org/misc/entrance.git/commit/?id=6f9dd39de7f45c27bb5d39188f0f5e31163680c5

commit 6f9dd39de7f45c27bb5d39188f0f5e31163680c5
Author: Michael Bouchaud 
Date:   Thu Oct 31 00:04:14 2013 +

entrance: missing an author
---
 AUTHORS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/AUTHORS b/AUTHORS
index 39f0e73..d478652 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -1,3 +1,4 @@
 Michael Bouchaud alias yoz 
 Carsten Haitzler 
 Maxime Villard 
+Cedric Bail 

-- 

Re: [E-devel] [EGIT] [misc/entrance] master 01/01: entrance: many improvment * improve pam login * fix some profile mistake when login an user * use EINA_UNUSED * code refactoring * remove session log

[David Seikel]

On Thu, 31 Oct 2013 00:51:21 +0100 Michaël Bouchaud  wrote:

> I will try to find my best words.
> Sorry to annoy you with a huge commit. But as I say before, I'm the
> main dev of entrance and the only one to take care about it. And I do
> it in my free times, as my contribution to the efl libraries and
> enlightenment since a long time.
> Raster or cedric have made some contribution to entrance before. But
> it was a long time ago. The last diff I see, from another than me, is
> from raster, where is a diff is on a pam file (not C code). Raster
> don't see I provide a file for debian-ubuntu pam...
> So I take this into account that an advanced user, who don't notice I
> provide this one. So I change my mind and today, I provide a debian
> pam file in first. (the second pam file is for gentoo or arch. Where
> I think user are welcome and get used to do some patch or custom cp
> for things to work, instead of ubuntu users...).
> But this is not the problem here. I just want you point out, I have
> some users who use entrance everyday and welcome to have the last
> revision to test it. We have migrated from svn to git. OK. They do
> it, and since I still have about 10 mails each months for entrance...
> Now I have 4 choices.
> - First one, try to do atomic commit to pleased you and have some
> review from nobody...(maybe cedric for some commit not all, where he
> will say nothing...). As I said before, I don't want to spare my time
> for that.
> - Second choice, don't do atomic commit... and nobody can (want)
> review me. But I will annoy some people with my huge commit (where
> this people can configure mailing box to ignore it as said by kuri).

That second choice works for me.  I'm not annoyed, and I'm planning on
giving entrance another go now, especially if it has better Ubuntu
support now.  It's good to see it being worked on.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[The Rasterman]

On Wed, 30 Oct 2013 12:58:41 -0300 Vinícius dos Santos Oliveira
 said:

> Em Qui, 2013-10-31 às 00:48 +0900, Carsten Haitzler escreveu:
> 
> > this is simply a matter of time. spend 1hr adding a feature someone
> > wants, or 1
> > hr writing docs.
> 
> 
> Documentation is a feature too.

in this case - for the minority of people. :)

> > i personally use docs as reference only - i ALWAYS use example
> > codee. nothing to do with java - it simply is faster, easier and more
> > practical.
> 
> Documentation can include snippets.

yes - i know. i prefer just code. get rid of the english fluff.

> > i read unix man pages to begin with and frankly they told me very
> > little at all. a whole tonne of words for very little use. examples
> > taught me
> > 100x more in the same amount of effort with docs backing it up as
> > reference.
> 
> Comparing manpages with HTML rich (or even PDFs) docs.> 
> 
>   * Manpages cannot have images (maybe with Terminology this is no
> longer true) and for a GUI toolkit this is kind of a must.
>   * Manpages don't have an easily browsable content (like HTML) have

i know. i spent some of my early life on unix/linux paying large sums for
o'reilly books. and reading them cover to cover. they had diagrams. i frankly
far prefer raw simple code over those books. the code is digestible in a
fraction of the time. :) if i have an actual working bit of code i can compile
it, run it and then modify it to see how it wobbles when poked. poke a bit more
and see some more wobbling. these wobbles tell me the story of how CHANGES to
the example affect the behaviour. start small with small changes and see. :) a
book doesn't give me that. english words don't give me that. code does. :) but
that is my style - i know that within all fields of education including foreign
languages, math, science, etc. etc. i always gravitated to "learn by example".
i naturally break up the examples into their constituent parts and know how to
manipulate them - the pattern builds over time naturally.

all i can offer here is - don't go massively rewrite some code within an app or
toolkit you are not immensely familiar with. start small. start with some
really minor augmentations very minor, and one small thing at a time - work
towards what you ultimately want. each step teaches you something important. :)

>   * Summary
>   * Detailed description and extra sections
>   * Extra pages (not directly related to one class only)
>   * A small text for each function

actually man pages do have these. ever seen the "see also" section? it is
effectively links to other related pages. :) i've read a LOT of man pages. :)

> > as such most of efl does have docs. they are not voluminous essays.
> > again - a
> > matter of time. if you wish to contribute by writing voluminous docs..
> > go for
> > it. :)
> 
> 
> The magic of open source. :)

indeed. :)

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


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[The Rasterman]

On Wed, 30 Oct 2013 14:49:27 -0400 Robert Heller  said:

> At Wed, 30 Oct 2013 13:43:45 -0400 Enlightenment users discussion & support
>wrote:
> 
> > 
> > On Wed, Oct 30, 2013 at 1:02 PM, Robert Heller  wrote:
> > 
> > > At Wed, 30 Oct 2013 12:09:52 -0400 Enlightenment users discussion &
> > > support  wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > Just to chime in with 10c's worth.
> > > >
> > > > This is my personal preference, working examples atleast as a base works
> > > > for me ( examples as in code )...  Documentaions words are ok for the
> > > nitty
> > > > gritty but not as a substitute for a good example.
> > > >
> > > > If you look at most tech books, the question is how many of us read any
> > > of
> > > > them cover to cover?.
> > >
> > >   But *I* do find them *very* useful, even if I don't read them cover to
> > > cover.
> > >   Often reading a page here or there (or even a whole section) if *very*
> > > useful,
> > >   and *not* because of the included examples.  And an *important* part of
> > > any
> > >   tech book is its index and/or table of contents -- either/both of these
> > > gets
> > >   me to the page or section I need to read.
> > >
> > 
> > 
> > Fair comment,
> > 
> > 
> > 
> > >
> > > >
> > > > Probably near none at all, so really for me thats enough said.
> > > >
> > >
> > > The main problem with documentation-by-example is what happens when there
> > > isn't an example that covers the question at hand? Or (worse) when the
> > > example's name or title does not fully suggest or explain what it is an
> > > example of. Also, sometimes it is critical when looking at examples that
> > > there
> > > is some explaination of the concepts involved. Examples alone can never
> > > really
> > > explain how to do things, if the *underlying* concepts are not either
> > > known or
> > > else explained. For example, what does 'swallow' mean in the context of
> > > edje?
> > > The code in e_menu is using this, but I have no clue as to what is going
> > > on and the swallow example does not really *explain* what is going on, it
> > > just shows you how to use it, without explaining why you would do it or
> > > what its purpose is. Somehow, I don't think it has anything to do with
> > > eating or birds (but maybe it does?).
> > >
> > >
> > I think at this stage, perhaps it would be good to take the opportunity to
> > take a look at the documentation available.
> 
> I have, and it is not *useful* -- there isn't any explaination of what is
> really going on. The 'Swallow Example' does not really explain what
> "edje_object_part_swallow(edje_obj, "part_one", rect);" does. There does not
> seem to be a *useful* explaination of what edje_object_part_swallow() does,

http://docs.enlightenment.org/stable/edje/Edje_8h.html#a1d9a921c4e78fd9a2879ae8a7b7c0bc9

as a reference efl is pretty good. it tells you precisely what swalllow does.
that's pretty accurate in that reference too.

> why you should use it (or not). It is there in the code I copied from
> e_menu.c, but I have no clue whether or not it is or is the reason I am not
> seeing anything useful on the screen. Or if I need to add something to the
> .edc file or what I should add to the .edc file.

what you are lacking is simply experience with a codebase AND a whole toolkit
that is rather large and complex. from what you write here you are jumping into
something relatively complex at the start without having masttered the basics.

> Bascially, *none* of the edje_* *C* functions are explained in any detail,
> the examples, just show their use, within the context of the given examples,
> but without the explaination needed to extrapolate to other contexts.

i see a rather large set of text describing swallowing an object above. to me
that text is already rather verbose. :)

> Maybe the problem is that *I* have not absorbed the 'culture' behind the E17 
> project.  I have not worked with a *C* based GUI API in some time (the last C 
> based GUI API I worked with was Motif).  Most of the GUI programming I have 
> been doing for the past 20+ years has been with Tcl/Tk.  (I have been coding 
> in C and C++ all though that time, but the C code has not been GUI coding -- 
> the C and C++ code ends up as a loadable shared library loaded into a Tcl/Tk 
> main program that implements the GUI, if any.)

i think that is the key here. you have strayed into an entirely foreign land.
while c itself is familiar - everything else is utterly strange and foreign.
trust me - knowing c or c++ gets you maybe 0.5% of the way there. the other
99.5% if the toolkit and e's code itself (for your situation). and that means
understanding a very large set of complex interactions between a vast set of
different libraires, api's and abstractions. no document is ever goign to
sensibly cover ALL of that. if i had to hazard a guess as to a document that
might, it'd probably be many times the size of war and peace (remember that it
has to cover not just the expplicit 

Re: [E-devel] [EGIT] [misc/entrance] master 01/01: entrance: many improvment * improve pam login * fix some profile mistake when login an user * use EINA_UNUSED * code refactoring * remove session log

[The Rasterman]

On Wed, 30 Oct 2013 22:03:29 +0100 Guillaume Friloux
 said:

> Hello guys, i dont put quotes as there would be too many things to quote 
> and i want my mail to be short.
> 
> Entrance is used by a bunch(maybe i should define 'bunch') of peoples, 
> already using this git repo.
> The fact that yoz is the only active dev on it ATM doesnt makes it a 
> personnal project. A project is defined "personnal" when there is only 
> one user, not one dev.
> In my opinion, this project has enough users to be in /misc/ or /apps/, 
> and not be isolated in /devs/ repo (or start to also move ecrire, 
> ephoto, etc). It is also a very interesting project that needs audience, 
> hidding it in /devs/ is BAD.
> 
> You guys are asking rules to be respected on a project you dont even own 
> (leading to "lets put this out of repos").
> If his patches bothers you, while you are not even working on it, you 
> can configure your mail client to filter those commits and mark them as 
> read instead of making changes that would affect michael and all the 
> entrance users.
> 
> Michael already does atomic commits on all the /efl/ patches he does, so 
> he doesnt have to be told about that.
> If you join his project and start working on it, then im pretty sure he 
> will start to do a lot of nice things for you, even explaining his code 
> and answering every question.
> 
> Re-reading my mail, it can seem rude, but its not, its just 'clear'.

i don't think it's rude. i have no problem with yoz's work on entrance. i know
its entrance and i can just skip reading diffs/git commits. it's easy to do. if
i become interested in it deeply - i will read them. as such i messed with
entrance again aftera  while away a few months back and got it working but
there was something utterly weird going on with session handling + systemd so
that basically the session dbus was missing the systemd api's to inhibit
suspend etc which is actually what i wanted to work. i tried figuring out why
and couldnt - so i had to back off, but in the process of using entrance i
fixed a slew of issues to make it work. :)

as such at this moment entrance is not ready for release or "prime time". it's
still needs work - especially lots of integration testing etc. BUT... it has
promise and the day it's ready - make noise and encourage people to try it
or ... try it again. :) i'm more than happy to work with someone as to what the
issue is/was with the session bus and systemd... but i'm not sure who...

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


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Monitor/output parameter for fullscreen

[Gustavo Sverzut Barbieri]

On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli  wrote:
> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli  
>> wrote:
>>> Hey everyone,
>>>
>>> Our current API for setting a window as fullscreen does not support
>>> specifying which output/display/monitor should be used as fullscreen.
>>> However, wayland does support it.
>>>
>>> Would it make sense to have such parameter in the fullscreen_set API?
>>> Or should it be a wayland-only API?
>>
>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
>> NULL = unset */
>>
>> the current version remains and sets on current display. Alternatively
>> we could just move the window to another display before making that
>> fullscreen, no idea if this is okay.
>
> Yeah, current version sets on current display (the one where the
> non-fullscreen window is already displayed), unless it's the first
> time that the window is going to be displayed. Otherwise it will use
> the first output. But that's up to the compositor to choose so far,
> unless we explicitly specify which output to use.
>
>>> For the latter case, how would we do that? Maybe exposing an API that
>>> allows to set the "preferred" output, and then when fullscreen_set is
>>> called, it just uses that one?
>>
>> I'd say we need to make this in one go, unless we want some kind of
>> general assignment to one display (not just for FS mode).
>
> OK...
>
>>
>>> There's also a need to specify how the output should be referred to.
>>> Using an (unsigned) int, where 0 is the first output, 1 is the second,
>>> etc? Or maybe allowing to specify something like "always the biggest
>>> one in area", or the widest one, or whatever... any thoughts?
>>
>> We'd need a way to enumerate the displays (or whatever we call them,
>> like zone, etc), they should return their properties such as size,
>> position (?), capabilities (3d/stereo? color? what do we have here?)
>> and some string to make it easy to debug.
>>
>> we have the handle to it, so it can be windowsystem agnostic
>> (Display_ID *, which can be implemented differently for windows, x11,
>> wayland...)
>
> So you are proposing that we change a good portion of our API to be
> aware of multiple displays?
>
>>
>>> That reminds me that we still have another problem. APIs such
>>> ecore_wl_screen_size_get() return only the screen size of the first
>>> monitor, not both.
>>
>> same as above, this should be based on current window (if there is a
>> window handle) or the first one (if there is not, alterntively we can
>> state it will refer to screen the mouse is over, but I guess this is
>> incorrect and makes everything less predictable).
>
> Well, that API has no argument, so it just assumes the current output.
> For a given window, one could use ecore_evas_screen_geometry_get, and
> that indeed will be attached to a given display, but only after the
> Ecore_Evas has been shown first (at least on Wayland, if I'm not
> wrong).
>
>>> What about a common API to select which output we are talking about,
>>> that must be called before any call that would refer to a specific
>>> output? The problem with this is that it would make code very
>>> wayland-specific :-/
>>
>> how so? just use the opaque handlers and abstract stuff in there.
>
> OK, so you suggestion is something like:
>
> Display {
>   ID;
>   size;
>   position; // might be some info from xrandr, like right-of another
> display, etc, if that is even possible
>   capabilities (3d/stereo? color?)
>   dpi (I'm not even sure if we can query different DPIs for different
> monitors, but I've seen discussion about future work on this on
> Wayland);
> }
>
> And then change/add some APIs to refer to a specific display when
> setting things?

change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.

then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).

-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (19) 9225-2202
Contact: http://www.gustavobarbieri.com.br/contact

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Monitor/output parameter for fullscreen

[Cedric BAIL]

On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
 wrote:
> On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli  
> wrote:
>> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli  
>>> wrote:
 Hey everyone,

 Our current API for setting a window as fullscreen does not support
 specifying which output/display/monitor should be used as fullscreen.
 However, wayland does support it.

 Would it make sense to have such parameter in the fullscreen_set API?
 Or should it be a wayland-only API?
>>>
>>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
>>> NULL = unset */
>>>
>>> the current version remains and sets on current display. Alternatively
>>> we could just move the window to another display before making that
>>> fullscreen, no idea if this is okay.
>>
>> Yeah, current version sets on current display (the one where the
>> non-fullscreen window is already displayed), unless it's the first
>> time that the window is going to be displayed. Otherwise it will use
>> the first output. But that's up to the compositor to choose so far,
>> unless we explicitly specify which output to use.
>>
 For the latter case, how would we do that? Maybe exposing an API that
 allows to set the "preferred" output, and then when fullscreen_set is
 called, it just uses that one?
>>>
>>> I'd say we need to make this in one go, unless we want some kind of
>>> general assignment to one display (not just for FS mode).
>>
>> OK...
>>
>>>
 There's also a need to specify how the output should be referred to.
 Using an (unsigned) int, where 0 is the first output, 1 is the second,
 etc? Or maybe allowing to specify something like "always the biggest
 one in area", or the widest one, or whatever... any thoughts?
>>>
>>> We'd need a way to enumerate the displays (or whatever we call them,
>>> like zone, etc), they should return their properties such as size,
>>> position (?), capabilities (3d/stereo? color? what do we have here?)
>>> and some string to make it easy to debug.
>>>
>>> we have the handle to it, so it can be windowsystem agnostic
>>> (Display_ID *, which can be implemented differently for windows, x11,
>>> wayland...)
>>
>> So you are proposing that we change a good portion of our API to be
>> aware of multiple displays?
>>
>>>
 That reminds me that we still have another problem. APIs such
 ecore_wl_screen_size_get() return only the screen size of the first
 monitor, not both.
>>>
>>> same as above, this should be based on current window (if there is a
>>> window handle) or the first one (if there is not, alterntively we can
>>> state it will refer to screen the mouse is over, but I guess this is
>>> incorrect and makes everything less predictable).
>>
>> Well, that API has no argument, so it just assumes the current output.
>> For a given window, one could use ecore_evas_screen_geometry_get, and
>> that indeed will be attached to a given display, but only after the
>> Ecore_Evas has been shown first (at least on Wayland, if I'm not
>> wrong).
>>
 What about a common API to select which output we are talking about,
 that must be called before any call that would refer to a specific
 output? The problem with this is that it would make code very
 wayland-specific :-/
>>>
>>> how so? just use the opaque handlers and abstract stuff in there.
>>
>> OK, so you suggestion is something like:
>>
>> Display {
>>   ID;
>>   size;
>>   position; // might be some info from xrandr, like right-of another
>> display, etc, if that is even possible
>>   capabilities (3d/stereo? color?)
>>   dpi (I'm not even sure if we can query different DPIs for different
>> monitors, but I've seen discussion about future work on this on
>> Wayland);
>> }
>>
>> And then change/add some APIs to refer to a specific display when
>> setting things?
>
> change is impossible at this time (abi/api stability) and cumbersome
> for most apps that don't care.

Indeed.

> then we must add new apis for those apps that care (ie: a presentation
> tool might offer a way to choose in which display to have a fullscreen
> view of slides while the notes/timer may be fullscreen on another).

Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ? That will limit the number of function
we add and will not make the API to ugly in my point of view.
-- 
Cedric BAIL

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk

[EGIT] [core/efl] master 01/03: evas: fix uninitialized use of font instance when no font is selected.

[Cedric Bail]

cedric pushed a commit to branch master.

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

commit e9614a9fddbc80da7061aae47b0e4f9cea1282e6
Author: Cedric Bail 
Date:   Tue Oct 29 17:00:48 2013 +0900

evas: fix uninitialized use of font instance when no font is selected.
---
 src/lib/evas/canvas/evas_object_text.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/lib/evas/canvas/evas_object_text.c 
b/src/lib/evas/canvas/evas_object_text.c
index 5dc38a8..5922d1b 100644
--- a/src/lib/evas/canvas/evas_object_text.c
+++ b/src/lib/evas/canvas/evas_object_text.c
@@ -641,9 +641,9 @@ static const Eina_Unicode _ellip_str[2] = { 0x2026, '\0' };
 static Evas_Object_Text_Item *
 _layout_ellipsis_item_new(Evas_Object_Protected_Data *obj, Evas_Object_Text *o)
 {
-   Evas_Object_Text_Item *ellip_ti;
+   Evas_Object_Text_Item *ellip_ti = NULL;
Evas_Script_Type script;
-   Evas_Font_Instance *script_fi = NULL, *cur_fi;
+   Evas_Font_Instance *script_fi = NULL, *cur_fi = NULL;
size_t len = 1; /* The length of _ellip_str */
 
script = evas_common_language_script_type_get(_ellip_str, 1);
@@ -652,11 +652,10 @@ _layout_ellipsis_item_new(Evas_Object_Protected_Data 
*obj, Evas_Object_Text *o)
  {
 (void) ENFN->font_run_end_get(ENDT, o->font, &script_fi, &cur_fi,
   script, _ellip_str, 1);
+   ellip_ti = _evas_object_text_item_new(obj, o, cur_fi,
+ _ellip_str, script, 0, 0, len);
  }
 
-   ellip_ti = _evas_object_text_item_new(obj, o, cur_fi,
- _ellip_str, script, 0, 0, len);
-
return ellip_ti;
 }
 

-- 

[EGIT] [core/efl] master 02/03: edje: make functions in Text API return Eina_Bool.

[Vorobiov Vitalii]

cedric pushed a commit to branch master.

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

commit 2ae3f6902bfa8bf6acb99d455736fb7830498b44
Author: Vorobiov Vitalii 
Date:   Thu Oct 31 11:04:11 2013 +0900

edje: make functions in Text API return Eina_Bool.

Make the following functions return Eina_Bool so the caller can detect 
errors:
edje_edit_state_text_set
edje_edit_state_text_size_set
edje_edit_state_text_align_x_set
edje_edit_state_text_align_y_set
edje_edit_state_text_elipsis_set
edje_edit_state_text_fit_x_set
edje_edit_state_text_fit_y_set
edje_edit_state_text_min_x_set
edje_edit_state_text_min_y_set
edje_edit_state_text_max_x_set
edje_edit_state_text_max_y_set

Reviewers: cedric, seoz

CC: reutskiy.v.v

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Edit.h | 51 +---
 src/lib/edje/edje_edit.c | 61 ++--
 2 files changed, 71 insertions(+), 41 deletions(-)

diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index ca521b5..efd7055 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -55,7 +55,7 @@ typedef struct _Edje_Edit_Script_Error Edje_Edit_Script_Error;
  * @brief Functions to deal with edje internal object. Don't use in standard
  * situations. The use of any of the edje_edit_* functions can break your
  * theme ability, remember that the program must be separated from the 
interface!
- * 
+ *
  * This was intended ONLY for use in an actual edje editor program. Unless
  * you are writing one of these, do NOT use this API here.
  *
@@ -2227,8 +2227,10 @@ EAPI const char * edje_edit_state_text_get(Evas_Object 
*obj, const char *part, c
  * @param state The name of the state to set text (not including the state 
value).
  * @param value The state value.
  * @param text The new text to assign.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE - otherwise.
  */
-EAPI void edje_edit_state_text_set(Evas_Object *obj, const char *part, const 
char *state, double value,const char *text);
+EAPI Eina_Bool edje_edit_state_text_set(Evas_Object *obj, const char *part, 
const char *state, double value,const char *text);
 
 /** Get font name for a given part state.
  *
@@ -2273,12 +2275,15 @@ EAPI int edje_edit_state_text_size_get(Evas_Object 
*obj, const char *part, const
  * @param state The name of the state to set text size (not including the 
state value).
  * @param value The state value.
  * @param size The new font size to set (in pixel)
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE - otherwise.
  */
-EAPI void edje_edit_state_text_size_set(Evas_Object *obj, const char *part, 
const char *state, double value, int size);
+EAPI Eina_Bool edje_edit_state_text_size_set(Evas_Object *obj, const char 
*part, const char *state, double value, int size);
 
 /** Get the text horizontal align of a part state.
  *
  * The value range is from 0.0(right) to 1.0(left)
+ * If the value is between -1.0 and 0.0 then it uses align automatically.
  *
  * @param obj Object being edited.
  * @param part Part that contain state.
@@ -2305,14 +2310,17 @@ EAPI double 
edje_edit_state_text_align_y_get(Evas_Object *obj, const char *part,
 /** Set the text horizontal align of a part state.
  *
  * The value range is from 0.0(right) to 1.0(left)
+ * If the value is between -1.0 and 0.0 then it uses align automatically.
  *
  * @param obj Object being edited.
  * @param part Part that contain state.
  * @param state The name of the state to set the text horizontal align (not 
including the state value).
  * @param value The state value.
  * @param align The new text horizontal align value
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE - otherwise.
  */
-EAPI void edje_edit_state_text_align_x_set(Evas_Object *obj, const char *part, 
const char *state, double value, double align);
+EAPI Eina_Bool edje_edit_state_text_align_x_set(Evas_Object *obj, const char 
*part, const char *state, double value, double align);
 
 /** Set the text vertical align of a part state.
  *
@@ -2323,12 +2331,14 @@ EAPI void edje_edit_state_text_align_x_set(Evas_Object 
*obj, const char *part, c
  * @param state The name of the state to set the text vertical align (not 
including the state value).
  * @param value The state value.
  * @param align The new text vertical align value
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE - otherwise.
  */
-EAPI void edje_edit_state_text_align_y_set(Evas_Object *obj, const char *part, 
const char *state, double value, double align);
+EAPI Eina_Bool edje_edit_state_text_align_y_set(Evas_Object *obj, const char 
*part, const char *state, double value, double align);
 
 /** Get the text elipsis of a part state.
  *
- * The value range is from 0.0(right) to 1.0(left)
+ * The value range is from 0.0(right) 

[EGIT] [core/efl] master 03/03: edje: make functions return Eina_Bool and fix documentation.

[Vorobiov Vitalii]

cedric pushed a commit to branch master.

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

commit 3038d41ba1070b3b5c4e682429fbfad4ea4fbea9
Author: Vorobiov Vitalii 
Date:   Thu Oct 31 11:05:42 2013 +0900

edje: make functions return Eina_Bool and fix documentation.

Make the following functions return Eina_Bool so the caller can detect 
errors:
edje_edit_state_font_set
edje_edit_part_effect_set

Also deleted duplicate of the "edje_edit_state_font_set" function in 
Edje_Edit.h
Moved some defines (EDJE_TEXT_EFFECT_MASK_BASIC, 
EDJE_TEXT_EFFECT_MASK_SHADOW_DIRECTION etc),
so doxygen generation was fixed.
Also added link (see also) in "edje_edit_part_effect_set" to the 
Edje_Text_Effect enum.

Reviewers: cedric, seoz

CC: reutskiy.v.v

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

Signed-off-by: Cedric Bail 
---
 src/lib/edje/Edje_Common.h | 12 +++-
 src/lib/edje/Edje_Edit.h   | 22 +-
 src/lib/edje/edje_edit.c   | 19 +--
 3 files changed, 29 insertions(+), 24 deletions(-)

diff --git a/src/lib/edje/Edje_Common.h b/src/lib/edje/Edje_Common.h
index 8ae1e57..8e72b75 100644
--- a/src/lib/edje/Edje_Common.h
+++ b/src/lib/edje/Edje_Common.h
@@ -1211,11 +1211,16 @@ typedef enum _Edje_Part_Type
  * @{
  */
 
-typedef enum _Edje_Text_Effect
-{
 #define EDJE_TEXT_EFFECT_MASK_BASIC 0xf
 #define EDJE_TEXT_EFFECT_BASIC_SET(x, s) \
do { x = ((x) & ~EDJE_TEXT_EFFECT_MASK_BASIC) | (s); } while (0)
+
+#define EDJE_TEXT_EFFECT_MASK_SHADOW_DIRECTION (0x7 << 4)
+#define EDJE_TEXT_EFFECT_SHADOW_DIRECTION_SET(x, s) \
+   do { x = ((x) & ~EDJE_TEXT_EFFECT_MASK_SHADOW_DIRECTION) | (s); } while (0)
+
+typedef enum _Edje_Text_Effect
+{
EDJE_TEXT_EFFECT_NONE= 0,
EDJE_TEXT_EFFECT_PLAIN   = 1,
EDJE_TEXT_EFFECT_OUTLINE = 2,
@@ -1230,9 +1235,6 @@ typedef enum _Edje_Text_Effect
 
EDJE_TEXT_EFFECT_LAST= 11,
 
-#define EDJE_TEXT_EFFECT_MASK_SHADOW_DIRECTION (0x7 << 4)
-#define EDJE_TEXT_EFFECT_SHADOW_DIRECTION_SET(x, s) \
-   do { x = ((x) & ~EDJE_TEXT_EFFECT_MASK_SHADOW_DIRECTION) | (s); } while (0)
EDJE_TEXT_EFFECT_SHADOW_DIRECTION_BOTTOM_RIGHT = (0x0 << 4),
EDJE_TEXT_EFFECT_SHADOW_DIRECTION_BOTTOM   = (0x1 << 4),
EDJE_TEXT_EFFECT_SHADOW_DIRECTION_BOTTOM_LEFT  = (0x2 << 4),
diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index efd7055..77dfff9 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -908,12 +908,17 @@ EAPI Eina_Bool edje_edit_part_source_set(Evas_Object 
*obj, const char *part, con
 EAPI Edje_Text_Effect edje_edit_part_effect_get(Evas_Object *obj, const char 
*part);
 
 /** Set the effect for a given part.
+ * Effects and shadow directions can be combined.
+ *
+ * For effect and shadow direction list please look at Edje Part Text ref page.
  *
  * @param obj Object being edited.
  * @param part Part to set the effect to. Only makes sense on type TEXT.
  * @param effect Effect to set for the part.
+ *
+ * @see Edje_Part_Text
  */
-EAPI void edje_edit_part_effect_set(Evas_Object *obj, const char *part, 
Edje_Text_Effect effect);
+EAPI Eina_Bool edje_edit_part_effect_set(Evas_Object *obj, const char *part, 
Edje_Text_Effect effect);
 
 /** Get the current selected state in part.
  *
@@ -2254,8 +2259,10 @@ EAPI const char * edje_edit_state_font_get(Evas_Object 
*obj, const char *part, c
  * @param state State in which the font is set.
  * @param value Value of the state.
  * @param font The font name to use.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE - otherwise.
  */
-EAPI void edje_edit_state_font_set(Evas_Object *obj, const char *part, const 
char *state, double value, const char *font);
+EAPI Eina_Bool edje_edit_state_font_set(Evas_Object *obj, const char *part, 
const char *state, double value, const char *font);
 
 /** Get the text size of a part state
  *
@@ -2561,17 +2568,6 @@ EAPI const char *edje_edit_font_path_get(Evas_Object 
*obj, const char *alias);
  */
 EAPI const char * edje_edit_state_font_get(Evas_Object *obj, const char *part, 
const char *state, double value);
 
-/** Set font name for a given part state.
- *
- * @param obj Object being edited.
- * @param part Part that contain state.
- * @param state The name of the state to set the name of the font that will be 
used (not including the state value).
- * @param value The state value.
- * @param font The name of the font to use in the given part state.
- */
-EAPI void edje_edit_state_font_set(Evas_Object *obj, const char *part, const 
char *state, double value, const char *font);
-
-
 //@}
 
/**/
 /**   IMAGES API   
/
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index 6cc37b2..34dfb45 100644
--- a/src/

Re: [E-devel] [EGIT] [misc/entrance] master 01/01: entrance: many improvment * improve pam login * fix some profile mistake when login an user * use EINA_UNUSED * code refactoring * remove session log

[The Rasterman]

On Thu, 31 Oct 2013 00:51:21 +0100 Michaël Bouchaud  said:

> I will try to find my best words.
> Sorry to annoy you with a huge commit. But as I say before, I'm the main
> dev of entrance and the only one to take care about it. And I do it in my
> free times, as my contribution to the efl libraries and enlightenment since
> a long time.
> Raster or cedric have made some contribution to entrance before. But it was
> a long time ago. The last diff I see, from another than me, is from raster,
> where is a diff is on a pam file (not C code). Raster don't see I provide a
> file for debian-ubuntu pam...

umm actually i did a lot more than that:

e51ff8cd2501304d3cee33621a3e520204e4f4b9
38f369b419e9fef8090dc75b1321fb3d0a61c07a
c05de4d019d590157b2edabce1aa808e63f28da1
16d33cdc4df0cc9e5063bb9c8a0b5fb77d4dc7bc
530e75cf7453398c059f3d6bc487766b83591a6d
688276f3259eee7da29a3b7e046b0ab2c33365fd
4d4cdc967c08fcd126704ece6b2d2394b91f1b22
981bf81dbb1820e2e74536926ab00336b58b43a1

all on sept 4. :) but either way - not a lot. :)

> So I take this into account that an advanced user, who don't notice I
> provide this one. So I change my mind and today, I provide a debian pam
> file in first. (the second pam file is for gentoo or arch. Where I think
> user are welcome and get used to do some patch or custom cp for things to
> work, instead of ubuntu users...).
> But this is not the problem here. I just want you point out, I have some
> users who use entrance everyday and welcome to have the last revision to
> test it. We have migrated from svn to git. OK. They do it, and since I
> still have about 10 mails each months for entrance...

as such entrance was in svn before and it's in git in the same way. thats how
it was and how it continues. i think here is a little too much focus on
"rules" and what i see as a desire to build more bureaucracy that "everyone
must follow the rules" "fill out form x" "get approval y". it's heading that
way. and that's a good way to lose developers. just leave entrance alone. let
it do its thing. if yoz wants to mess with it - fine. until it's up on
enlightenment.org as a download tarball and something that the wider project is
pushing/supporting, it doesn't much matter. ignore the commits on it unless
*YOU* use it and those commits affect you. :) the day yoz wants to push
entrance to become a released/up for download thing... lets deal with it then
and maybe bring entrance under some more control.

> Now I have 4 choices.
> - First one, try to do atomic commit to pleased you and have some review
> from nobody...(maybe cedric for some commit not all, where he will say
> nothing...). As I said before, I don't want to spare my time for that.
> - Second choice, don't do atomic commit... and nobody can (want) review me.
> But I will annoy some people with my huge commit (where this people can
> configure mailing box to ignore it as said by kuri).

i think just filtering (ignoring the commits) is the best way - if you don't
care about the project.. ignore its commits.

> - Third choice, as second choice don't do atomic commit, but my project go
> in my dev dir. Here my user will be annoyed, because he don't be noticed by
> recent changes and I lose my futur audience ...
> - Fourth choice, don't do atomic commit... and open my own github. And I
> will annoy my user for a last time and don't boring you again.

i think this is the worst option. i think just keep entrance exactly as it is.
keep doing your work. i sure am not going to review every commit to it even if
they were perfectly scripted and gold plated with cherries on top. it's not
important to at this time. if i use entrance, i will whack at its code to make
it work if it does not. if a feature doesn't work right - i'll fix it. if it's
missing something i need - i'll add it. pretty simple. commits can always be
reverted.

> But in last, if the last choice comes to be the best one. I will be very
> sad to go away from this repositories, because I think entrance could be a
> good publicity. Further, entrance works like a charm for years, and I try
> to not b0rk it...

hmm in sept i had to fix a tonne of stuff where it segv'd all over the place
and really did not work. :) thus my commits. :) i had many more changes i had
locally that conflicted with changes you made and i dropped them. :) entrance
imho is on its way there to being "ready to go" - but not there yet. :)

> In last, but I can't say "ok, I go to my own dev dir and don't boring you
> again" here. But I understand your point of view. So, I let you assume your
> remarks and futur decision. I'm not the one who have coded 90% percent of
> code of efl libs so I can't be a dictator to make some decision. I just
> want to have some arrangement with you on this point.
> 
> PS: I never be remunerated for my contribution to efl libs or elementary,
> if I have succesfully imposed the efl and enlightenment in my last jobs. I
> always do my dev on the efl libraries on my free time as I do for entranc

Re: [E-devel] Monitor/output parameter for fullscreen

[The Rasterman]

On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL  said:

> On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
>  wrote:
> > On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli 
> > wrote:
> >> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
> >>  wrote:
> >>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli 
> >>> wrote:
>  Hey everyone,
> 
>  Our current API for setting a window as fullscreen does not support
>  specifying which output/display/monitor should be used as fullscreen.
>  However, wayland does support it.
> 
>  Would it make sense to have such parameter in the fullscreen_set API?
>  Or should it be a wayland-only API?
> >>>
> >>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
> >>> NULL = unset */
> >>>
> >>> the current version remains and sets on current display. Alternatively
> >>> we could just move the window to another display before making that
> >>> fullscreen, no idea if this is okay.
> >>
> >> Yeah, current version sets on current display (the one where the
> >> non-fullscreen window is already displayed), unless it's the first
> >> time that the window is going to be displayed. Otherwise it will use
> >> the first output. But that's up to the compositor to choose so far,
> >> unless we explicitly specify which output to use.
> >>
>  For the latter case, how would we do that? Maybe exposing an API that
>  allows to set the "preferred" output, and then when fullscreen_set is
>  called, it just uses that one?
> >>>
> >>> I'd say we need to make this in one go, unless we want some kind of
> >>> general assignment to one display (not just for FS mode).
> >>
> >> OK...
> >>
> >>>
>  There's also a need to specify how the output should be referred to.
>  Using an (unsigned) int, where 0 is the first output, 1 is the second,
>  etc? Or maybe allowing to specify something like "always the biggest
>  one in area", or the widest one, or whatever... any thoughts?
> >>>
> >>> We'd need a way to enumerate the displays (or whatever we call them,
> >>> like zone, etc), they should return their properties such as size,
> >>> position (?), capabilities (3d/stereo? color? what do we have here?)
> >>> and some string to make it easy to debug.
> >>>
> >>> we have the handle to it, so it can be windowsystem agnostic
> >>> (Display_ID *, which can be implemented differently for windows, x11,
> >>> wayland...)
> >>
> >> So you are proposing that we change a good portion of our API to be
> >> aware of multiple displays?
> >>
> >>>
>  That reminds me that we still have another problem. APIs such
>  ecore_wl_screen_size_get() return only the screen size of the first
>  monitor, not both.
> >>>
> >>> same as above, this should be based on current window (if there is a
> >>> window handle) or the first one (if there is not, alterntively we can
> >>> state it will refer to screen the mouse is over, but I guess this is
> >>> incorrect and makes everything less predictable).
> >>
> >> Well, that API has no argument, so it just assumes the current output.
> >> For a given window, one could use ecore_evas_screen_geometry_get, and
> >> that indeed will be attached to a given display, but only after the
> >> Ecore_Evas has been shown first (at least on Wayland, if I'm not
> >> wrong).
> >>
>  What about a common API to select which output we are talking about,
>  that must be called before any call that would refer to a specific
>  output? The problem with this is that it would make code very
>  wayland-specific :-/
> >>>
> >>> how so? just use the opaque handlers and abstract stuff in there.
> >>
> >> OK, so you suggestion is something like:
> >>
> >> Display {
> >>   ID;
> >>   size;
> >>   position; // might be some info from xrandr, like right-of another
> >> display, etc, if that is even possible
> >>   capabilities (3d/stereo? color?)
> >>   dpi (I'm not even sure if we can query different DPIs for different
> >> monitors, but I've seen discussion about future work on this on
> >> Wayland);
> >> }
> >>
> >> And then change/add some APIs to refer to a specific display when
> >> setting things?
> >
> > change is impossible at this time (abi/api stability) and cumbersome
> > for most apps that don't care.
> 
> Indeed.
> 
> > then we must add new apis for those apps that care (ie: a presentation
> > tool might offer a way to choose in which display to have a fullscreen
> > view of slides while the notes/timer may be fullscreen on another).
> 
> Why not just a ecore_evas_screen_set/get/list() set of functions that
> will affect the screen attached to a window for all coming request on
> the pointed Ecore_Evas window ? That will limit the number of function
> we add and will not make the API to ugly in my point of view.

i think this way is nicer. add a new api that sets a requested/hinted/desired
"screen" on a window and THEN if u fullscreen it this requested screen is
passed along with the fu

Re: [E-devel] [e-users] Is there *real* documentation for edje?

[Cedric BAIL]

Hello,

On Thu, Oct 31, 2013 at 3:49 AM, Robert Heller  wrote:
> At Wed, 30 Oct 2013 13:43:45 -0400 Enlightenment users discussion & support   
>wrote:
>> On Wed, Oct 30, 2013 at 1:02 PM, Robert Heller  wrote:
>> > At Wed, 30 Oct 2013 12:09:52 -0400 Enlightenment users discussion &
>> > support  wrote:
>> I think at this stage, perhaps it would be good to take the opportunity to
>> take a look at the documentation available.
>
> I have, and it is not *useful* -- there isn't any explaination of what is
> really going on. The 'Swallow Example' does not really explain what
> "edje_object_part_swallow(edje_obj, "part_one", rect);" does. There does not
> seem to be a *useful* explaination of what edje_object_part_swallow() does,
> why you should use it (or not). It is there in the code I copied from
> e_menu.c, but I have no clue whether or not it is or is the reason I am not
> seeing anything useful on the screen. Or if I need to add something to the
> .edc file or what I should add to the .edc file.
>
> Bascially, *none* of the edje_* *C* functions are explained in any detail, the
> examples, just show their use, within the context of the given examples, but
> without the explaination needed to extrapolate to other contexts.

Some example come with documentation around them. Sometimes it is
broken. If I look at edje swallow example, I get to this page :
https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/tutorial_edje_swallow2.html
.
Obviously there is a problem. I don't know what is going on exactly,
but something is wrong somewhere.

At the same time the fact that you don't find the documentation about
edje_object_part_swallow is something that will be hard to understand
for anyone around for to long with EFL. It is so core that people get
to understand it and nobody bothered to write an expensive
documentation after they pass that point. And the more experienced
with EFL the more difficult it become to write a documentation for
beginners (I would be really bad at it for example, since it seems
really trivial to me after rewriting half of edje).

That's why I have always advocated that new comers, once they
understand something that wasn't obvious should not hesitate to submit
patch to our documentation. It would be a very valuable contribution
to this community, so don't hesitate. And as you are doing now, if you
can't find your answer in our current documentation. Ask here on the
mailing-list or on our IRC channel. It is also part of the
documentation process.

You will see that the documentation for swallow come from
http://git.enlightenment.org/core/efl.git/tree/src/lib/edje/Edje_Legacy.h#n1471
and the example come from :
http://git.enlightenment.org/core/efl.git/tree/doc/edje_examples.dox#n1079
. Obviously any patch to any of those file to match more what you
would have expected from the documentation is highly welcomed.

I think raster did answer the question regarding what a swallow is.
But to summarize it another way, is that when you swallow an object
into an edje object, you give up on controlling its layout and
visibility from the C code and let that to be done by an .edc file
with a SWALLOW part. It is how EFL decouple theme from C.
-- 
Cedric BAIL

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/02: evil: remove libgen and the GNU *printf code (both in mingw-w64).

[Vincent Torri]

cedric pushed a commit to branch master.

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

commit 6e043dfb44006b7b48d1f54f907c00417fcf6baf
Author: Vincent Torri 
Date:   Tue Oct 29 16:15:21 2013 +0100

evil: remove libgen and the GNU *printf code (both in mingw-w64).

This should reduce the code size of evil and reduce maintainance as
mingw does now take care of it.

Signed-off-by: Cedric Bail 
---
 pc/evil.pc.in |   2 +-
 src/Makefile_Evil.am  |  39 +---
 src/lib/evil/Evil.h   |   3 --
 src/lib/evil/evil_inet.c  |   4 +-
 src/lib/evil/evil_inet.h  |   2 +-
 src/lib/evil/evil_macro.h | 100 --
 src/lib/evil/evil_macro_pop.h |  25 ---
 src/lib/evil/evil_mman.c  |   3 --
 src/lib/evil/evil_stdlib.c|   2 -
 src/lib/evil/evil_util.c  |   2 -
 10 files changed, 4 insertions(+), 178 deletions(-)

diff --git a/pc/evil.pc.in b/pc/evil.pc.in
index 6f5f085..cf4b855 100644
--- a/pc/evil.pc.in
+++ b/pc/evil.pc.in
@@ -10,4 +10,4 @@ Description: Library that ports on Windows some specific Unix 
functions.
 Version: @VERSION@
 Libs: -L${libdir} -levil
 Libs.private:
-Cflags: -I${includedir}/evil-@VMAJ@ @EFL_WINDOWS_VERSION_CFLAGS@ -mms-bitfields
+Cflags: -I${includedir}/evil-@VMAJ@ @EFL_WINDOWS_VERSION_CFLAGS@ 
-mms-bitfields -D__MINGW_PRINTF_FORMAT
diff --git a/src/Makefile_Evil.am b/src/Makefile_Evil.am
index af8512b..9e68b6e 100644
--- a/src/Makefile_Evil.am
+++ b/src/Makefile_Evil.am
@@ -10,11 +10,9 @@ lib/evil/Evil.h \
 lib/evil/evil_fcntl.h \
 lib/evil/evil_inet.h \
 lib/evil/evil_langinfo.h \
-lib/evil/evil_libgen.h \
 lib/evil/evil_macro.h \
 lib/evil/evil_macro_pop.h \
 lib/evil/evil_main.h \
-lib/evil/evil_print.h \
 lib/evil/evil_stdlib.h \
 lib/evil/evil_stdio.h \
 lib/evil/evil_string.h \
@@ -34,49 +32,15 @@ evilmmanheadersdir = $(includedir)/evil-@VMAJ@/sys
 dist_evilmmanheaders_DATA = \
 lib/evil/sys/mman.h
 
-# gdtoa
 lib_evil_libevil_la_SOURCES = \
-lib/evil/gdtoa/arithchk.c \
-lib/evil/gdtoa/dmisc.c \
-lib/evil/gdtoa/dtoa.c \
-lib/evil/gdtoa/gd_arith.h \
-lib/evil/gdtoa/g_dfmt.c \
-lib/evil/gdtoa/gd_qnan.h \
-lib/evil/gdtoa/gdtoa.c \
-lib/evil/gdtoa/gdtoa_fltrnds.h \
-lib/evil/gdtoa/gdtoa.h \
-lib/evil/gdtoa/gdtoaimp.h \
-lib/evil/gdtoa/gethex.c \
-lib/evil/gdtoa/g_ffmt.c \
-lib/evil/gdtoa/g__fmt.c \
-lib/evil/gdtoa/gmisc.c \
-lib/evil/gdtoa/g_xfmt.c \
-lib/evil/gdtoa/hd_init.c \
-lib/evil/gdtoa/hexnan.c \
-lib/evil/gdtoa/misc.c \
-lib/evil/gdtoa/qnan.c \
-lib/evil/gdtoa/smisc.c \
-lib/evil/gdtoa/strtodg.c \
-lib/evil/gdtoa/strtof.c \
-lib/evil/gdtoa/strtopx.c \
-lib/evil/gdtoa/sum.c \
-lib/evil/gdtoa/ulp.c
-
-#evil
-lib_evil_libevil_la_SOURCES += \
 lib/evil/evil_dirent.c \
 lib/evil/evil_fcntl.c \
 lib/evil/evil_fnmatch.c \
 lib/evil/evil_fnmatch_list_of_states.c \
 lib/evil/evil_inet.c \
 lib/evil/evil_langinfo.c \
-lib/evil/evil_libgen.c \
 lib/evil/evil_main.c \
 lib/evil/evil_mman.c \
-lib/evil/evil_pformata.c \
-lib/evil/evil_pformatw.c \
-lib/evil/evil_printa.c \
-lib/evil/evil_printw.c \
 lib/evil/evil_pwd.c \
 lib/evil/evil_stdlib.c \
 lib/evil/evil_stdio.c \
@@ -85,7 +49,6 @@ lib/evil/evil_time.c \
 lib/evil/evil_unistd.c \
 lib/evil/evil_util.c \
 lib/evil/evil_uuid.c \
-lib/evil/evil_pformat.h \
 lib/evil/evil_private.h \
 lib/evil/evil_fnmatch_private.h
 
@@ -95,7 +58,7 @@ else
 lib_evil_libevil_la_SOURCES += lib/evil/evil_link_xp.cpp
 endif
 
-lib_evil_libevil_la_CFLAGS = @EVIL_CFLAGS@ @EVIL_CFLAGS_WRN@
+lib_evil_libevil_la_CFLAGS = @EVIL_CFLAGS@ @EVIL_CFLAGS_WRN@ 
-D__MINGW_PRINTF_FORMAT
 lib_evil_libevil_la_CXXFLAGS = @EVIL_CXXFLAGS@ @EVIL_CFLAGS@
 lib_evil_libevil_la_LIBADD = @EVIL_LIBS@
 lib_evil_libevil_la_LDFLAGS = @EFL_LTLIBRARY_FLAGS@
diff --git a/src/lib/evil/Evil.h b/src/lib/evil/Evil.h
index eb84ec6..e629d76 100644
--- a/src/lib/evil/Evil.h
+++ b/src/lib/evil/Evil.h
@@ -71,7 +71,6 @@
  * Recommended reading:
  *
  * @li @ref Evil_Mman
- * @li @ref Evil_Libgen_Group
  * @li @ref Evil_Unistd_Group
  * @li @ref Evil_Dlfcn
  * @li @ref Evil_Pwd_Group
@@ -152,9 +151,7 @@ typedef unsigned long  gid_t;
 #include "evil_fcntl.h"
 #include "evil_inet.h"
 #include "evil_langinfo.h"
-#include "evil_libgen.h"
 #include "evil_main.h"
-#include "evil_print.h"
 #include "evil_stdlib.h"
 #include "evil_stdio.h"
 #include "evil_string.h"
diff --git a/src/lib/evil/evil_inet.c b/src/lib/evil/evil_inet.c
index c24ebaf..e455d0e 100644
--- a/src/lib/evil/evil_inet.c
+++ b/src/lib/evil/evil_inet.c
@@ -22,7 +22,7 @@
  * * modification of the management of the error
  */
 
-#if ! _WIN32_WINNT >= _WIN32_WINNT_VISTA
+#if ! (_WIN32_WINNT >= _WIN32_WINNT_VISTA)
 
 #ifdef HAVE_CONFIG_H
 # include "config.h"
@@ -41,8 +41,6 @@
 #include "evil_macro.h"
 #include "evil_inet.h"
 #include "evil_private.h"
-#define APICHAR char
-#include "evil_print.h"
 
 #ifndef EMSGSIZE
 # define EMSGSIZE WSAEMSGSIZE
diff --git a/src/lib/evil/evil_

[EGIT] [core/efl] master 02/02: evil: add missing define specific to Windows build.

[Cedric Bail]

cedric pushed a commit to branch master.

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

commit 88912c06a82ca840c5b30a9e0d56dcdffc40fdf3
Author: Cedric Bail 
Date:   Thu Oct 31 14:39:21 2013 +0900

evil: add missing define specific to Windows build.

It is an optional flags that just shutdown useless warning at build time.
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index 413264a..9e1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,7 @@ case "$host_os" in
   # TODO: check cygwin* here
   have_win32="yes"
   have_windows="yes"
+  EFL_CFLAGS="${EFL_CFLAGS} -D__MINGW_PRINTF_FORMAT"
;;
darwin*)
   have_darwin="yes"

-- 

[EGIT] [core/efl] master 01/01: evil: let's try another combinaison of define.

[Cedric Bail]

cedric pushed a commit to branch master.

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

commit f5d6d09d197dd0dad5609747d9dc558fd960f612
Author: Cedric Bail 
Date:   Thu Oct 31 15:39:12 2013 +0900

evil: let's try another combinaison of define.
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 9e1..f783c49 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,7 +189,7 @@ case "$host_os" in
   # TODO: check cygwin* here
   have_win32="yes"
   have_windows="yes"
-  EFL_CFLAGS="${EFL_CFLAGS} -D__MINGW_PRINTF_FORMAT"
+  EFL_CFLAGS="${EFL_CFLAGS} -D__USE_MINGW_ANSI_STDIO"
;;
darwin*)
   have_darwin="yes"

--