Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

[The Rasterman]

On Tue, 15 Nov 2016 12:03:14 +0900 (KST) Hermet Park  said:

> As considering further, we'd rather avoid path interface for the optimization
> point.
> 
> Current downside of the evas_vg, it needs to copy the path data to the ector,
> since both ector and evas_vg inherit gfx_shape.
> 
> But If the path is an independent instance, 
> it's possible that evas_vg just pass the path instance to the ector with the
> ref count increase. Plus, ector and evas_vg track the path changes flexibly.
> 
> Additionally, user just need to set one path data for several vg objects if
> those vg objects may need to have same path information.
> 
> So, again, I aim to Eina again.
> 
> What do you think?

it already has rectangles, and "tile buffer" which is really a rectangle
"update region" system which are really just data structures. it has matrix
stuff which frankle is used 90% of the time for gfx. quadtrees are data structs
almost exclusively used for gfx (2d regions/arrays of stuff). it has vectors.
gfx. eina has a lot of "basic gfx related data types" in it. i don't see
another lib as being useful here. another lib simply adds MORE problems. we
have issues already where we have SO MANY .so's on some systems efl fails
because we cant dlopen more libs at all. ran out of __thread slots. this is not
an optimization. it's a real bug that we cant solve without either:

1. telling people to upgrade.patch libc
or
2. us reducing the number of .so's we have.

forget optimizing. we need to do this just to stop having things fail entirely.
dont add another lib that then has to be merged anyway.

now to naming... i dislike eina_path - like many i think of file path first,
not gfx path. if anything maybe call it eina_shape? or eina_outline or
eina_poly? (polygons, beziers - just be rough and call them polyline/curve
segments).

> -Original Message-
> From: "Carsten Haitzler" 
> To: "Enlightenment developer
> list"; Cc: 
> Sent: 2016-11-15 (화) 08:25:19
> Subject: Re: [E-devel] FW: FW: FW: FW: Propose a Eina_Path
>  
> On Mon, 14 Nov 2016 22:54:15 + Andrew Williams 
> said:
> 
> > Rect seems to mirror quite well the path discussion I think - a data
> > structure vs a graphical context...
> > 
> > I see now how a non-gfx rectangle helps communicate data but can the
> > graphical react not extend data structure type rect so they are more
> > interoperable? Additionally it is strange to define these in the same
> > library as true/false and storage primitives are declared imho.
> > 
> > I wonder if we are missing a supporting gfx-structures lib that Evas and
> > many others could depend upon? And path and Rect would belong there...
> 
> no not another library. we have too many and have to REDUCE not expand.
> 
> > Andrew
> > On Mon, 14 Nov 2016 at 11:21, Hermet Park  wrote:
> > 
> > > Eina_Rectangle  => A data structure.
> > > Evas_Rectangle => A drawing primitive.
> > >
> > > Sorry, but I thought rect is a bit digressed to this topic.
> > >
> > > I'm not a negative even though path is not going in Eina.
> > >
> > > But let's consider more realitic position.
> > >
> > > I think path is unlike to an interface but it's more to be an individual
> > > data set.
> > >
> > > And efl_gfx_shape is likely to depend on this.
> > >
> > > If you agree that it could be an interface, then efl_gfx_path may be also
> > > fine.
> > >
> > > but not in ector/evas because efl interface is lower than them.
> > >
> > > -Original Message-
> > > From: "Andrew Williams"
> > > To: "Enlightenment developer list"<
> > > enlightenment-devel@lists.sourceforge.net>;
> > > Cc:
> > > Sent: 2016-11-14 (월) 17:51:31
> > > Subject: Re: [E-devel] FW: FW: FW: Propose a Eina_Path
> > >
> > > I think that even if a shape is not going to be rendered it is still a
> > > graphical concept.
> > > In most frameworks I can find it is in a graphics, geometry or gui
> > > namespace.
> > >
> > > Eina is already becoming ambiguous in its purpose and adding shapes in
> > > there seems confusing.
> > >
> > > Is it just me who is confused that Eina_Rectangle and Evas_Rect both
> > > exist?
> > >
> > > Andy
> > > On Mon, 14 Nov 2016 at 02:16, Hermet Park  wrote:
> > >
> > > > elm_path well..  it's not a concreted idea yet, but we may provide that
> > > > kind of feasible object like a elm_flip for an arbitrary shaped objects.
> > > >
> > > > I don't know about elm_chart but guess it does not have a simliar
> > > > concept with path object.
> > > > Because the traditional charts have been designed for a sort of vector
> > > > wise graphical drawing like lines, bars and *pizza* pies etc.
> > > > but this path is majorly designed  for binding our graphcial objects
> > > > onto an arbitrary path.
> > > >
> > > > See the next some screenshots.
> > > >
> > > > https://phab.enlightenment.org/F48119
> > > > 

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

[Cedric BAIL]

On Mon, Nov 14, 2016 at 7:03 PM, Hermet Park  wrote:
> As considering further, we'd rather avoid path interface for the optimization 
> point.

I don't see any performance issue as most of the math and cost is into
the computation of the curve not setting a string/combo of command,
but maybe you have some benchmark in that regard ? I haven't looked at
any benchmark on our current vector stack, so you might well be right.

> Current downside of the evas_vg, it needs to copy the path data to the ector, 
> since both ector and evas_vg inherit gfx_shape.

Yes, it does copy a list of command and point with two arrays if I
remember correctly. Those array are pretty small and shouldn't become
that huge. If you think it might become a concern at some point, maybe
we can introduce a structure in Eina that does refcounting, allocation
and destruction (Something Eina_Safepointer should be ble to do, I
guess). No need for the path primitive to be there.

> But If the path is an independent instance,
> it's possible that evas_vg just pass the path instance to the ector with the 
> ref count increase.
> Plus, ector and evas_vg track the path changes flexibly.

See above proposal, that address your problem without putting pressure
on the binding generation and increasing the mess to much in eina

> Additionally, user just need to set one path data for several vg objects if 
> those vg objects may need to have same path information.

I guess, but is that a common pattern ?

> So, again, I aim to Eina again.
>
> What do you think?

As above, add arrays to a structure managed by an opaque
Eina_Safepointer that is shareable among instance of efl_gfx_path.eo.
-- 
Cedric BAIL

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

[E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

[Hermet Park]

As considering further, we'd rather avoid path interface for the optimization 
point.

Current downside of the evas_vg, it needs to copy the path data to the ector, 
since both ector and evas_vg inherit gfx_shape.

But If the path is an independent instance, 
it's possible that evas_vg just pass the path instance to the ector with the 
ref count increase.
Plus, ector and evas_vg track the path changes flexibly.

Additionally, user just need to set one path data for several vg objects if 
those vg objects may need to have same path information.

So, again, I aim to Eina again.

What do you think?

-Original Message-
From: "Carsten Haitzler" 
To: "Enlightenment developer list"; 
Cc: 
Sent: 2016-11-15 (화) 08:25:19
Subject: Re: [E-devel] FW: FW: FW: FW: Propose a Eina_Path
 
On Mon, 14 Nov 2016 22:54:15 + Andrew Williams  said:

> Rect seems to mirror quite well the path discussion I think - a data
> structure vs a graphical context...
> 
> I see now how a non-gfx rectangle helps communicate data but can the
> graphical react not extend data structure type rect so they are more
> interoperable? Additionally it is strange to define these in the same
> library as true/false and storage primitives are declared imho.
> 
> I wonder if we are missing a supporting gfx-structures lib that Evas and
> many others could depend upon? And path and Rect would belong there...

no not another library. we have too many and have to REDUCE not expand.

> Andrew
> On Mon, 14 Nov 2016 at 11:21, Hermet Park  wrote:
> 
> > Eina_Rectangle  => A data structure.
> > Evas_Rectangle => A drawing primitive.
> >
> > Sorry, but I thought rect is a bit digressed to this topic.
> >
> > I'm not a negative even though path is not going in Eina.
> >
> > But let's consider more realitic position.
> >
> > I think path is unlike to an interface but it's more to be an individual
> > data set.
> >
> > And efl_gfx_shape is likely to depend on this.
> >
> > If you agree that it could be an interface, then efl_gfx_path may be also
> > fine.
> >
> > but not in ector/evas because efl interface is lower than them.
> >
> > -Original Message-
> > From: "Andrew Williams"
> > To: "Enlightenment developer list"<
> > enlightenment-devel@lists.sourceforge.net>;
> > Cc:
> > Sent: 2016-11-14 (월) 17:51:31
> > Subject: Re: [E-devel] FW: FW: FW: Propose a Eina_Path
> >
> > I think that even if a shape is not going to be rendered it is still a
> > graphical concept.
> > In most frameworks I can find it is in a graphics, geometry or gui
> > namespace.
> >
> > Eina is already becoming ambiguous in its purpose and adding shapes in
> > there seems confusing.
> >
> > Is it just me who is confused that Eina_Rectangle and Evas_Rect both exist?
> >
> > Andy
> > On Mon, 14 Nov 2016 at 02:16, Hermet Park  wrote:
> >
> > > elm_path well..  it's not a concreted idea yet, but we may provide that
> > > kind of feasible object like a elm_flip for an arbitrary shaped objects.
> > >
> > > I don't know about elm_chart but guess it does not have a simliar concept
> > > with path object.
> > > Because the traditional charts have been designed for a sort of vector
> > > wise graphical drawing like lines, bars and *pizza* pies etc.
> > > but this path is majorly designed  for binding our graphcial objects onto
> > > an arbitrary path.
> > >
> > > See the next some screenshots.
> > >
> > > https://phab.enlightenment.org/F48119
> > > https://phab.enlightenment.org/F48120
> > > https://phab.enlightenment.org/F48121
> > > https://phab.enlightenment.org/F48122
> > >
> > > If you have more than the chart idea than I expected then please share it
> > > to us.
> > >
> > > Also, I don't see extending efl_gfx_shape is not the answer here.
> > > If path object is introduced in elm, path won't need all shape stuff.
> > > Even some usage may just require only path data without graphical
> > drawing.
> > > So rather than that, modulization(divide path) should be considerd for
> > > shape now.
> > >
> > > Honestly, I'm not quite sure which place is the best for the path
> > > interface but at least Eina for now.
> > > Even necessary of path eo binding. of course, path naming could be
> > > considered in case of Eina.
> > >
> > >
> > > -Original Message-
> > > From: "Cedric BAIL"
> > > To: "e-devel";
> > > Cc:
> > > Sent: 2016-11-12 (토) 01:41:58
> > > Subject: Re: [E-devel] FW: FW: Propose a Eina_Path
> > >
> > > On Nov 11, 2016 04:39, "Andrew Williams"  wrote:
> > > >
> > > > It strange that eina defines a rectangle and no other shapes - is that
> > > even
> > > > used outside a graphical context?
> > >
> > >
> > > Eina started as a simple toolset and got a lot of stuff that was just
> > > refactoring of our stack. We have a tiler and 

Re: [E-devel] FW: FW: FW: FW: Propose a Eina_Path

[The Rasterman]

On Mon, 14 Nov 2016 22:54:15 + Andrew Williams  said:

> Rect seems to mirror quite well the path discussion I think - a data
> structure vs a graphical context...
> 
> I see now how a non-gfx rectangle helps communicate data but can the
> graphical react not extend data structure type rect so they are more
> interoperable? Additionally it is strange to define these in the same
> library as true/false and storage primitives are declared imho.
> 
> I wonder if we are missing a supporting gfx-structures lib that Evas and
> many others could depend upon? And path and Rect would belong there...

no not another library. we have too many and have to REDUCE not expand.

> Andrew
> On Mon, 14 Nov 2016 at 11:21, Hermet Park  wrote:
> 
> > Eina_Rectangle  => A data structure.
> > Evas_Rectangle => A drawing primitive.
> >
> > Sorry, but I thought rect is a bit digressed to this topic.
> >
> > I'm not a negative even though path is not going in Eina.
> >
> > But let's consider more realitic position.
> >
> > I think path is unlike to an interface but it's more to be an individual
> > data set.
> >
> > And efl_gfx_shape is likely to depend on this.
> >
> > If you agree that it could be an interface, then efl_gfx_path may be also
> > fine.
> >
> > but not in ector/evas because efl interface is lower than them.
> >
> > -Original Message-
> > From: "Andrew Williams"
> > To: "Enlightenment developer list"<
> > enlightenment-devel@lists.sourceforge.net>;
> > Cc:
> > Sent: 2016-11-14 (월) 17:51:31
> > Subject: Re: [E-devel] FW: FW: FW: Propose a Eina_Path
> >
> > I think that even if a shape is not going to be rendered it is still a
> > graphical concept.
> > In most frameworks I can find it is in a graphics, geometry or gui
> > namespace.
> >
> > Eina is already becoming ambiguous in its purpose and adding shapes in
> > there seems confusing.
> >
> > Is it just me who is confused that Eina_Rectangle and Evas_Rect both exist?
> >
> > Andy
> > On Mon, 14 Nov 2016 at 02:16, Hermet Park  wrote:
> >
> > > elm_path well..  it's not a concreted idea yet, but we may provide that
> > > kind of feasible object like a elm_flip for an arbitrary shaped objects.
> > >
> > > I don't know about elm_chart but guess it does not have a simliar concept
> > > with path object.
> > > Because the traditional charts have been designed for a sort of vector
> > > wise graphical drawing like lines, bars and *pizza* pies etc.
> > > but this path is majorly designed  for binding our graphcial objects onto
> > > an arbitrary path.
> > >
> > > See the next some screenshots.
> > >
> > > https://phab.enlightenment.org/F48119
> > > https://phab.enlightenment.org/F48120
> > > https://phab.enlightenment.org/F48121
> > > https://phab.enlightenment.org/F48122
> > >
> > > If you have more than the chart idea than I expected then please share it
> > > to us.
> > >
> > > Also, I don't see extending efl_gfx_shape is not the answer here.
> > > If path object is introduced in elm, path won't need all shape stuff.
> > > Even some usage may just require only path data without graphical
> > drawing.
> > > So rather than that, modulization(divide path) should be considerd for
> > > shape now.
> > >
> > > Honestly, I'm not quite sure which place is the best for the path
> > > interface but at least Eina for now.
> > > Even necessary of path eo binding. of course, path naming could be
> > > considered in case of Eina.
> > >
> > >
> > > -Original Message-
> > > From: "Cedric BAIL"
> > > To: "e-devel";
> > > Cc:
> > > Sent: 2016-11-12 (토) 01:41:58
> > > Subject: Re: [E-devel] FW: FW: Propose a Eina_Path
> > >
> > > On Nov 11, 2016 04:39, "Andrew Williams"  wrote:
> > > >
> > > > It strange that eina defines a rectangle and no other shapes - is that
> > > even
> > > > used outside a graphical context?
> > >
> > >
> > > Eina started as a simple toolset and got a lot of stuff that was just
> > > refactoring of our stack. We have a tiler and rectangle along with
> > matrix,
> > > just from the top of my head. I clearly see the need for having a path
> > > primitive, the question is where and under what name. It would be fine in
> > > eina, if not for the name that is confusing. It would be fine in Ector,
> > if
> > > not for Ector depending on efl_gfx_shape. Thinking of it, for binding, we
> > > want this API to be in Eo. So why not extending efl_gfx_shape to provide
> > > what it is missing and have elementary use it.
> > >
> > >
> > > Added question what is the goal of elm_path object ? I am personnally
> > > looking forward to an elm_chart object a lot more.
> > >
> > >
> > > Best,
> > >
> > >   Cedric
> > >
> > >
> > > > A
> > > > On Fri, 11 Nov 2016 at 11:17, Hermet Park  wrote:
> > > >
> > > > > Thanks for your advice.
> > > > >
> > > > > But imo, it's unlike 

[EGIT] [core/efl] master 01/01: efreet: make mime type evaluation way faster by using mmap.

[Cedric BAIL]

cedric pushed a commit to branch master.

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

commit 6da2fbc9c432e3c845cdc0a3e647eeb27d582c33
Author: Cedric BAIL 
Date:   Mon Nov 14 15:16:32 2016 -0800

efreet: make mime type evaluation way faster by using mmap.
---
 src/lib/efreet/efreet_mime.c | 64 +---
 1 file changed, 24 insertions(+), 40 deletions(-)

diff --git a/src/lib/efreet/efreet_mime.c b/src/lib/efreet/efreet_mime.c
index 63e6b15..3197c97 100644
--- a/src/lib/efreet/efreet_mime.c
+++ b/src/lib/efreet/efreet_mime.c
@@ -1128,34 +1128,23 @@ efreet_mime_magic_check_priority(const char *file,
Efreet_Mime_Magic *m = NULL;
Efreet_Mime_Magic_Entry *e = NULL;
Eina_List *l, *ll;
-   FILE *f = NULL;
-   unsigned int i = 0, offset = 0,level = 0, match = 0, bytes_read = 0;
+   Eina_File *f = NULL;
+   const char *mem = NULL;
+   size_t sz;
+   unsigned int i = 0, offset = 0,level = 0, match = 0;
const char *last_mime = NULL;
int c;
-   char v, buf[EFREET_MIME_MAGIC_BUFFER_SIZE];
-   struct stat s;
+   char v;
 
-#ifdef _WIN32
-   if (stat(file, ) || s.st_size == 0)
-#else
-   if (lstat(file, ) || s.st_size == 0)
-#endif
-  return NULL;
+   if (!magics) return NULL;
 
-   f = fopen(file, "rb");
+   f = eina_file_open(file, EINA_FALSE);
if (!f) return NULL;
 
-   if (!magics)
- {
-fclose(f);
-return NULL;
- }
+   mem = eina_file_map_all(f, EINA_FILE_RANDOM);
+   if (!mem) goto end;
 
-   if ((bytes_read = fread(buf, 1, sizeof(buf), f)) == 0)
- {
-fclose(f);
-return NULL;
- }
+   sz = eina_file_size_get(f);
 
EINA_LIST_FOREACH(magics, l, m)
  {
@@ -1171,30 +1160,25 @@ efreet_mime_magic_check_priority(const char *file,
continue;
 
  if ((level >= e->indent) && !match)
-   level = e->indent;
-
+   {
+  level = e->indent;
+   }
  else if ((level > e->indent) && match)
{
-  fclose(f);
-  return last_mime;
+  goto end;
}
 
  for (offset = e->offset; offset < e->offset + e->range_len; 
offset++)
{
-  if (((offset + e->value_len) > bytes_read) &&
-  (fseek(f, offset, SEEK_SET) == -1))
-break;
+  if (offset + e->value_len >= sz) break;
 
   match = 1;
   for (i = 0; i < e->value_len; ++i)
 {
-   if (offset + e->value_len > bytes_read)
- c = fgetc(f);
-   else
- c = buf[offset + i];
+   c = mem[offset + i];
 
v = e->value[i];
-   if (e->mask) v &= e->mask[i];
+   if (e->mask) c &= e->mask[i];
 
if (!(c == v))
  {
@@ -1212,15 +1196,15 @@ efreet_mime_magic_check_priority(const char *file,
}
   }
 
-if (match)
-  {
- fclose(f);
- return last_mime;
-  }
+if (match) break;
  }
-   fclose(f);
 
-   return NULL;
+ end:
+   if (mem) eina_file_map_free(f, (void*) mem);
+
+   eina_file_close(f);
+
+   return last_mime;
 }
 
 /**

-- 

Re: [E-devel] drm page flip/animators etc.

[The Rasterman]

On Mon, 14 Nov 2016 16:06:13 -0600 Derek Foreman  said:

> On 13/11/16 07:15 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 13 Nov 2016 13:53:04 +0900 Carsten Haitzler (The Rasterman)
> >  said:
> >
> > oh... i now see the same issues with redraw/animator/whatever on nouveau as
> > i did on the rpi... so this is definitely broken-pants. :)
> 
> Excellent timing. :)
> 
> Until Friday, the animator_tick stuff used in the drm animator code was 
> broken - it didn't properly disable the timer based animator.  Both time 
> ticks and pageflips were firing at the same time.
> 
> This is the reason why we get an inconsistent buffer age, and end up 
> using more buffers than we should at times.
> 
> Cedric dealt with that Thursday, but that exposed a bug in my drm tick 
> code that was preventing pageflip based ticks from firing properly.  I 
> had it fixed locally, but didn't get a chance to sort the commits and push.
> 
> It should work better now.

it still has a miss-frame bug as below unless you redesigned it to queue flips
from a thread

> >> On Sun, 13 Nov 2016 12:31:49 +0900 Carsten Haitzler (The Rasterman)
> >>  said:
> >>
> >> FYI - i disabled _drm_animator_register, _drm_animator_unregister,
> >> _drm_evas_changed from the ecore_evbas func struct for the drm engine and
> >> lo and behold... mouse moves smoothly and reliably. yes. there are "gpu
> >> goes slow" hiccups but the whole drm animator stuff is really bad -
> >> especially on an rpi. : ( the elementary_test animation is now pretty
> >> decent. its smooth
> 
> It's not heavily tested and it has some bugs, but I think "really bad" 
> is a bit hyperbolic. :P

not hyperbolic. it's impossible to use a mouse, or close to it. i get maybe 1
fps or 0.5fps. the mouse moves at this rate. as does everything... UNTIL
another animator is continually on - eg like hovering over an ibar icon. then
its ok. i wouldnt call this hyperbolic.

> >> (well i disabled the manual render messing the wayland engine was doing as
> >> per below).
> 
> Good luck with that.  You can get dropped client frames (as in: the most 
> recent frame gets dropped and you sit there looking at a stale frame) 
> and maybe a deadlocked compositor under certain corner cases.
> 
> It would be probably be safer to wait for me to fix that than to 
> randomly badger it.
> 
> It's known broken and has been on my todo list for ages, it just isn't 
> broken enough to make it top priority.

it's still broken tho... just minorly (eg were someone else to use norender
push/pop in elm - and elm can do this automatically eg when minimizing etc. so
elm will mess with manual render as well as the ecore evas wl engine).

> >>
> >> this needs some serious testing across a wide range of hw (slow and fast)
> >> and careful thought on mainloop blocking conditions and how this affects
> >> everything etc.
> 
> What's blocking the main loop?!?

opengl rendering stuff. my time traces show a lot of the time its under 16ms
but then it goes over to like 20ms then takes 50ms then 80ms or whatever for 4
frames then back down to 12-13ms ... if you are close to the 16ms boundary...
you may miss a frame and thus drop from 60 ro 30hz as you just cannot queue a
page flip in time. by design the current scheme for drm page flip has this very
annoying bug. i discovered that in the vblank animator a long time ago and
fixed it by dedicating a thread to the task so it cant be blocked.

either way this is the main loop. it runs code totally out of control of efl.
an app could sit and calculate pi to 100283892392300348 decimal places or
calculate fractals or do blocking i/o that we cant control (even evas does
blocking i/o on image header decodes) and these add up. if you happen to miss
the timing for another page flip you have to WAIT for the next one and that
means your framerate suffers badly. you now SLEEP not even trying to render
another frame. you wait for the next page flip event which is maybe 14ms away
(if the last frame took 18ms) and THEN begin that render. as long as your
renders are nicely under 16ms (or whatever your frame gap is) then its fine,
but once you get just near or over it things go  bad with a scheme of inline
scheduling. you have to schedule at least several frames in advance then Or use
a scheme that can preempt and schedule anyway - eg a thread.

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


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

Re: [E-devel] FW: FW: FW: FW: Propose a Eina_Path

[Cedric BAIL]

On Mon, Nov 14, 2016 at 3:20 AM, Hermet Park  wrote:
> Eina_Rectangle  => A data structure.
> Evas_Rectangle => A drawing primitive.
>
> Sorry, but I thought rect is a bit digressed to this topic.
>
> I'm not a negative even though path is not going in Eina.
>
> But let's consider more realitic position.
>
> I think path is unlike to an interface but it's more to be an individual data 
> set.
>
> And efl_gfx_shape is likely to depend on this.
>
> If you agree that it could be an interface, then efl_gfx_path may be also 
> fine.

I think I can see use case for an efl_gfx_path and have efl_gfx_shape
inherit from it. Could be useful to define a path for example for the
icon size while mimicking engage effect.

> but not in ector/evas because efl interface is lower than them.

Especially because both ector/evas and even elementary need to be able
to see that interface. So it makes sense in efl_gfx interface
namespace.

Cedric

> -Original Message-
> From: "Andrew Williams"
> To: "Enlightenment developer list";
> Cc:
> Sent: 2016-11-14 (월) 17:51:31
> Subject: Re: [E-devel] FW: FW: FW: Propose a Eina_Path
>
> I think that even if a shape is not going to be rendered it is still a
> graphical concept.
> In most frameworks I can find it is in a graphics, geometry or gui
> namespace.
>
> Eina is already becoming ambiguous in its purpose and adding shapes in
> there seems confusing.
>
> Is it just me who is confused that Eina_Rectangle and Evas_Rect both exist?
>
> Andy
> On Mon, 14 Nov 2016 at 02:16, Hermet Park  wrote:
>
>> elm_path well..  it's not a concreted idea yet, but we may provide that
>> kind of feasible object like a elm_flip for an arbitrary shaped objects.
>>
>> I don't know about elm_chart but guess it does not have a simliar concept
>> with path object.
>> Because the traditional charts have been designed for a sort of vector
>> wise graphical drawing like lines, bars and *pizza* pies etc.
>> but this path is majorly designed  for binding our graphcial objects onto
>> an arbitrary path.
>>
>> See the next some screenshots.
>>
>> https://phab.enlightenment.org/F48119
>> https://phab.enlightenment.org/F48120
>> https://phab.enlightenment.org/F48121
>> https://phab.enlightenment.org/F48122
>>
>> If you have more than the chart idea than I expected then please share it
>> to us.
>>
>> Also, I don't see extending efl_gfx_shape is not the answer here.
>> If path object is introduced in elm, path won't need all shape stuff.
>> Even some usage may just require only path data without graphical drawing.
>> So rather than that, modulization(divide path) should be considerd for
>> shape now.
>>
>> Honestly, I'm not quite sure which place is the best for the path
>> interface but at least Eina for now.
>> Even necessary of path eo binding. of course, path naming could be
>> considered in case of Eina.
>>
>>
>> -Original Message-
>> From: "Cedric BAIL"
>> To: "e-devel";
>> Cc:
>> Sent: 2016-11-12 (토) 01:41:58
>> Subject: Re: [E-devel] FW: FW: Propose a Eina_Path
>>
>> On Nov 11, 2016 04:39, "Andrew Williams"  wrote:
>> >
>> > It strange that eina defines a rectangle and no other shapes - is that
>> even
>> > used outside a graphical context?
>>
>>
>> Eina started as a simple toolset and got a lot of stuff that was just
>> refactoring of our stack. We have a tiler and rectangle along with matrix,
>> just from the top of my head. I clearly see the need for having a path
>> primitive, the question is where and under what name. It would be fine in
>> eina, if not for the name that is confusing. It would be fine in Ector, if
>> not for Ector depending on efl_gfx_shape. Thinking of it, for binding, we
>> want this API to be in Eo. So why not extending efl_gfx_shape to provide
>> what it is missing and have elementary use it.
>>
>>
>> Added question what is the goal of elm_path object ? I am personnally
>> looking forward to an elm_chart object a lot more.
>>
>>
>> Best,
>>
>>   Cedric
>>
>>
>> > A
>> > On Fri, 11 Nov 2016 at 11:17, Hermet Park  wrote:
>> >
>> > > Thanks for your advice.
>> > >
>> > > But imo, it's unlike to graphical one such as evas_rect and
>> evas_line...
>> > > Path itself is more likely to the eina_rect...
>> > > Because path itself is just data information.
>> > > Also, efl_gfx_shape should rely on it.
>> > >
>> > > -Original Message-
>> > > From: "Andrew Williams"
>> > > To: "Enlightenment developer list"<
>> > > enlightenment-devel@lists.sourceforge.net>;
>> > > Cc:
>> > > Sent: 2016-11-11 (금) 20:07:44
>> > > Subject: Re: [E-devel] FW: Propose a Eina_Path
>> > >
>> > > Alongside Evas_Rect and Evas_Line?
>> > >
>> > > On Fri, 11 Nov 2016 at 08:59, Hermet Park  wrote:
>> > >
>> > > > Yes, but I have no idea about proper 

Re: [E-devel] FW: FW: FW: FW: Propose a Eina_Path

[Andrew Williams]

Rect seems to mirror quite well the path discussion I think - a data
structure vs a graphical context...

I see now how a non-gfx rectangle helps communicate data but can the
graphical react not extend data structure type rect so they are more
interoperable? Additionally it is strange to define these in the same
library as true/false and storage primitives are declared imho.

I wonder if we are missing a supporting gfx-structures lib that Evas and
many others could depend upon? And path and Rect would belong there...

Andrew
On Mon, 14 Nov 2016 at 11:21, Hermet Park  wrote:

> Eina_Rectangle  => A data structure.
> Evas_Rectangle => A drawing primitive.
>
> Sorry, but I thought rect is a bit digressed to this topic.
>
> I'm not a negative even though path is not going in Eina.
>
> But let's consider more realitic position.
>
> I think path is unlike to an interface but it's more to be an individual
> data set.
>
> And efl_gfx_shape is likely to depend on this.
>
> If you agree that it could be an interface, then efl_gfx_path may be also
> fine.
>
> but not in ector/evas because efl interface is lower than them.
>
> -Original Message-
> From: "Andrew Williams"
> To: "Enlightenment developer list"<
> enlightenment-devel@lists.sourceforge.net>;
> Cc:
> Sent: 2016-11-14 (월) 17:51:31
> Subject: Re: [E-devel] FW: FW: FW: Propose a Eina_Path
>
> I think that even if a shape is not going to be rendered it is still a
> graphical concept.
> In most frameworks I can find it is in a graphics, geometry or gui
> namespace.
>
> Eina is already becoming ambiguous in its purpose and adding shapes in
> there seems confusing.
>
> Is it just me who is confused that Eina_Rectangle and Evas_Rect both exist?
>
> Andy
> On Mon, 14 Nov 2016 at 02:16, Hermet Park  wrote:
>
> > elm_path well..  it's not a concreted idea yet, but we may provide that
> > kind of feasible object like a elm_flip for an arbitrary shaped objects.
> >
> > I don't know about elm_chart but guess it does not have a simliar concept
> > with path object.
> > Because the traditional charts have been designed for a sort of vector
> > wise graphical drawing like lines, bars and *pizza* pies etc.
> > but this path is majorly designed  for binding our graphcial objects onto
> > an arbitrary path.
> >
> > See the next some screenshots.
> >
> > https://phab.enlightenment.org/F48119
> > https://phab.enlightenment.org/F48120
> > https://phab.enlightenment.org/F48121
> > https://phab.enlightenment.org/F48122
> >
> > If you have more than the chart idea than I expected then please share it
> > to us.
> >
> > Also, I don't see extending efl_gfx_shape is not the answer here.
> > If path object is introduced in elm, path won't need all shape stuff.
> > Even some usage may just require only path data without graphical
> drawing.
> > So rather than that, modulization(divide path) should be considerd for
> > shape now.
> >
> > Honestly, I'm not quite sure which place is the best for the path
> > interface but at least Eina for now.
> > Even necessary of path eo binding. of course, path naming could be
> > considered in case of Eina.
> >
> >
> > -Original Message-
> > From: "Cedric BAIL"
> > To: "e-devel";
> > Cc:
> > Sent: 2016-11-12 (토) 01:41:58
> > Subject: Re: [E-devel] FW: FW: Propose a Eina_Path
> >
> > On Nov 11, 2016 04:39, "Andrew Williams"  wrote:
> > >
> > > It strange that eina defines a rectangle and no other shapes - is that
> > even
> > > used outside a graphical context?
> >
> >
> > Eina started as a simple toolset and got a lot of stuff that was just
> > refactoring of our stack. We have a tiler and rectangle along with
> matrix,
> > just from the top of my head. I clearly see the need for having a path
> > primitive, the question is where and under what name. It would be fine in
> > eina, if not for the name that is confusing. It would be fine in Ector,
> if
> > not for Ector depending on efl_gfx_shape. Thinking of it, for binding, we
> > want this API to be in Eo. So why not extending efl_gfx_shape to provide
> > what it is missing and have elementary use it.
> >
> >
> > Added question what is the goal of elm_path object ? I am personnally
> > looking forward to an elm_chart object a lot more.
> >
> >
> > Best,
> >
> >   Cedric
> >
> >
> > > A
> > > On Fri, 11 Nov 2016 at 11:17, Hermet Park  wrote:
> > >
> > > > Thanks for your advice.
> > > >
> > > > But imo, it's unlike to graphical one such as evas_rect and
> > evas_line...
> > > > Path itself is more likely to the eina_rect...
> > > > Because path itself is just data information.
> > > > Also, efl_gfx_shape should rely on it.
> > > >
> > > > -Original Message-
> > > > From: "Andrew Williams"
> > > > To: "Enlightenment developer list"<
> > > > enlightenment-devel@lists.sourceforge.net>;
> > > 

[EGIT] [core/efl] master 01/01: ecore_drm2: Follow direct crtc sets with a page flip

[Derek Foreman]

derekf pushed a commit to branch master.

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

commit 8368f6e1d269fb19781ed00d7bba636a703512df
Author: Derek Foreman 
Date:   Mon Nov 14 16:39:03 2016 -0600

ecore_drm2: Follow direct crtc sets with a page flip

Now that the bugs generating extra ticks are fixed, we need to make sure
we can actually generate one here.
---
 src/lib/ecore_drm2/ecore_drm2_fb.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/lib/ecore_drm2/ecore_drm2_fb.c 
b/src/lib/ecore_drm2/ecore_drm2_fb.c
index 7142ab1..149bb75 100644
--- a/src/lib/ecore_drm2/ecore_drm2_fb.c
+++ b/src/lib/ecore_drm2/ecore_drm2_fb.c
@@ -412,8 +412,11 @@ ecore_drm2_fb_flip(Ecore_Drm2_Fb *fb, Ecore_Drm2_Output 
*output)
  output->current = fb;
  output->current->busy = EINA_TRUE;
  output->next = NULL;
-
- return 0;
+ /* We used to return here, but now that the ticker is fixed this
+  * can leave us hanging waiting for a tick to happen forever.
+  * Instead, we now fall through the the flip path to make sure
+  * even this first set can cause a flip callback.
+  */
   }
 
 ret =

-- 

Re: [E-devel] drm page flip/animators etc.

[Derek Foreman]

On 13/11/16 07:15 PM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 13 Nov 2016 13:53:04 +0900 Carsten Haitzler (The Rasterman)
>  said:
>
> oh... i now see the same issues with redraw/animator/whatever on nouveau as i
> did on the rpi... so this is definitely broken-pants. :)

Excellent timing. :)

Until Friday, the animator_tick stuff used in the drm animator code was 
broken - it didn't properly disable the timer based animator.  Both time 
ticks and pageflips were firing at the same time.

This is the reason why we get an inconsistent buffer age, and end up 
using more buffers than we should at times.

Cedric dealt with that Thursday, but that exposed a bug in my drm tick 
code that was preventing pageflip based ticks from firing properly.  I 
had it fixed locally, but didn't get a chance to sort the commits and push.

It should work better now.

>> On Sun, 13 Nov 2016 12:31:49 +0900 Carsten Haitzler (The Rasterman)
>>  said:
>>
>> FYI - i disabled _drm_animator_register, _drm_animator_unregister,
>> _drm_evas_changed from the ecore_evbas func struct for the drm engine and lo
>> and behold... mouse moves smoothly and reliably. yes. there are "gpu goes
>> slow" hiccups but the whole drm animator stuff is really bad - especially on
>> an rpi. : ( the elementary_test animation is now pretty decent. its smooth

It's not heavily tested and it has some bugs, but I think "really bad" 
is a bit hyperbolic. :P

>> (well i disabled the manual render messing the wayland engine was doing as
>> per below).

Good luck with that.  You can get dropped client frames (as in: the most 
recent frame gets dropped and you sit there looking at a stale frame) 
and maybe a deadlocked compositor under certain corner cases.

It would be probably be safer to wait for me to fix that than to 
randomly badger it.

It's known broken and has been on my todo list for ages, it just isn't 
broken enough to make it top priority.

>>
>> this needs some serious testing across a wide range of hw (slow and fast) and
>> careful thought on mainloop blocking conditions and how this affects
>> everything etc.

What's blocking the main loop?!?


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

[EGIT] [core/efl] master 01/01: ecore_evas_drm: Fix bugs in pending tracking

[Derek Foreman]

derekf pushed a commit to branch master.

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

commit 20f52cd60703d8e3fc1496117a2c8cf9119b6284
Author: Derek Foreman 
Date:   Mon Nov 14 14:30:11 2016 -0600

ecore_evas_drm: Fix bugs in pending tracking

This has been dead wrong for a while but only recently became a
showstopper when another bug was fixed that made this one manifest.
---
 src/modules/ecore_evas/engines/drm/ecore_evas_drm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c 
b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
index 2d8e789..ac970f5 100644
--- a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
+++ b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
@@ -630,9 +630,14 @@ _cb_pageflip(int fd EINA_UNUSED, unsigned int frame 
EINA_UNUSED, unsigned int se
 double t = (double)sec + ((double)usec / 100);
 
 ecore_evas_animator_tick(ee, NULL, t);
+edata->pending = EINA_TRUE;
+ecore_drm2_fb_flip(NULL, edata->output);
+ }
+   else if (ret)
+ {
+edata->pending = EINA_TRUE;
 ecore_drm2_fb_flip(NULL, edata->output);
  }
-   else if (ret) ecore_drm2_fb_flip(NULL, edata->output);
 }
 
 static void
@@ -654,6 +659,7 @@ _drm_animator_register(Ecore_Evas *ee)
edata = ee->engine.data;
edata->ticking = EINA_TRUE;
if (!edata->pending) ecore_drm2_fb_flip(NULL, edata->output);
+   edata->pending = EINA_TRUE;
 }
 
 static void

-- 

[EGIT] [core/efl] master 01/01: ecore_evas_drm: Use timestamp from pageflip event for animator time

[Derek Foreman]

derekf pushed a commit to branch master.

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

commit bf7814aca01e9589062eedcd0d7807b4f3f90ce2
Author: Derek Foreman 
Date:   Mon Nov 14 14:12:58 2016 -0600

ecore_evas_drm: Use timestamp from pageflip event for animator time

Should be more accurate this way.
---
 src/modules/ecore_evas/engines/drm/ecore_evas_drm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c 
b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
index 79c1c58..2d8e789 100644
--- a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
+++ b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
@@ -612,7 +612,7 @@ _cb_drm_event(void *data, Ecore_Fd_Handler *hdlr 
EINA_UNUSED)
 }
 
 static void
-_cb_pageflip(int fd EINA_UNUSED, unsigned int frame EINA_UNUSED, unsigned int 
sec EINA_UNUSED, unsigned int usec EINA_UNUSED, void *data)
+_cb_pageflip(int fd EINA_UNUSED, unsigned int frame EINA_UNUSED, unsigned int 
sec, unsigned int usec, void *data)
 {
Ecore_Evas *ee;
Ecore_Evas_Engine_Drm_Data *edata;
@@ -627,7 +627,9 @@ _cb_pageflip(int fd EINA_UNUSED, unsigned int frame 
EINA_UNUSED, unsigned int se
 
if (edata->ticking)
  {
-ecore_evas_animator_tick(ee, NULL, ecore_loop_time_get());
+double t = (double)sec + ((double)usec / 100);
+
+ecore_evas_animator_tick(ee, NULL, t);
 ecore_drm2_fb_flip(NULL, edata->output);
  }
else if (ret) ecore_drm2_fb_flip(NULL, edata->output);

-- 

[EGIT] [core/efl] master 01/01: ecore_evas: fix evas_changed call

[Derek Foreman]

derekf pushed a commit to branch master.

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

commit 2480b4bb22aa9c8141e605561549dd7f848dc1ce
Author: Derek Foreman 
Date:   Mon Nov 14 14:03:16 2016 -0600

ecore_evas: fix evas_changed call

Don't or together all previously considered evases.  Thanks Cedric
for the catch.
---
 src/lib/ecore_evas/ecore_evas.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/lib/ecore_evas/ecore_evas.c b/src/lib/ecore_evas/ecore_evas.c
index c92d5cd..df382fa 100644
--- a/src/lib/ecore_evas/ecore_evas.c
+++ b/src/lib/ecore_evas/ecore_evas.c
@@ -174,15 +174,20 @@ _ecore_evas_idle_enter(void *data EINA_UNUSED)
 
 if (!ee->manual_render)
   {
+ Eina_Bool change = EINA_FALSE;
+
  if (ee->engine.func->fn_render)
-   rend |= ee->engine.func->fn_render(ee);
+   {
+  change = ee->engine.func->fn_render(ee);
+  rend |= change;
+   }
   /*
* Some engines that generate their own ticks based on hardware
* events need to know that render has been considered, and
* whether it will actually generate a new image or not
*/
  if (ee->engine.func->fn_evas_changed)
-   ee->engine.func->fn_evas_changed(ee, rend);
+   ee->engine.func->fn_evas_changed(ee, change);
   }
 #ifdef ECORE_EVAS_ASYNC_RENDER_DEBUG
 if ((ee->in_async_render) && (ee->async_render_start <= 0.0))

-- 

[EGIT] [core/efl] master 04/04: ecore: introduce adjusting main loop time on animator.

[Cedric BAIL]

cedric pushed a commit to branch master.

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

commit 8215d9832c3ae0e2889a528b08f8b462fb90cd69
Author: Cedric BAIL 
Date:   Mon Nov 14 11:53:01 2016 -0800

ecore: introduce adjusting main loop time on animator.
---
 src/lib/ecore_evas/ecore_evas.c | 8 +---
 src/lib/ecore_evas/ecore_evas_private.h | 2 +-
 src/modules/ecore_evas/engines/drm/ecore_evas_drm.c | 2 +-
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/lib/ecore_evas/ecore_evas.c b/src/lib/ecore_evas/ecore_evas.c
index d48394e..c92d5cd 100644
--- a/src/lib/ecore_evas/ecore_evas.c
+++ b/src/lib/ecore_evas/ecore_evas.c
@@ -2438,7 +2438,7 @@ _ecore_evas_fps_debug_rendertime_add(double t)
 static Ecore_Evas *_general_tick = NULL;
 
 EAPI void
-ecore_evas_animator_tick(Ecore_Evas *ee, Eina_Rectangle *viewport)
+ecore_evas_animator_tick(Ecore_Evas *ee, Eina_Rectangle *viewport, double 
loop_time)
 {
Ecore_Evas *subee;
Eina_List *l;
@@ -2453,13 +2453,15 @@ ecore_evas_animator_tick(Ecore_Evas *ee, Eina_Rectangle 
*viewport)
 a.update_area = *viewport;
  }
 
+   ecore_loop_time_set(loop_time);
+
ee->animator_ran = EINA_TRUE;
efl_event_callback_legacy_call(ee->evas, EFL_EVENT_ANIMATOR_TICK, );
 
// FIXME: We do not support partial animator in the subcanvas
EINA_LIST_FOREACH(ee->sub_ecore_evas, l, subee)
  {
-ecore_evas_animator_tick(subee, NULL);
+ecore_evas_animator_tick(subee, NULL, loop_time);
  }
 
// We are the source of sync for general animator.
@@ -2501,7 +2503,7 @@ _ecore_evas_tick_source_find(void)
 static Eina_Bool
 _ecore_evas_animator_fallback(void *data)
 {
-   ecore_evas_animator_tick(data, NULL);
+   ecore_evas_animator_tick(data, NULL, ecore_loop_time_get());
return EINA_TRUE;
 }
 
diff --git a/src/lib/ecore_evas/ecore_evas_private.h 
b/src/lib/ecore_evas/ecore_evas_private.h
index 432152f..e4642c7 100644
--- a/src/lib/ecore_evas/ecore_evas_private.h
+++ b/src/lib/ecore_evas/ecore_evas_private.h
@@ -436,7 +436,7 @@ const Eina_List *_ecore_evas_available_engines_get(void);
 void _ecore_evas_engine_init(void);
 void _ecore_evas_engine_shutdown(void);
 
-EAPI void ecore_evas_animator_tick(Ecore_Evas *ee, Eina_Rectangle *viewport);
+EAPI void ecore_evas_animator_tick(Ecore_Evas *ee, Eina_Rectangle *viewport, 
double loop_time);
 
 Eina_Module *_ecore_evas_vnc_server_module_load(void);
 
diff --git a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c 
b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
index ba97f5d..79c1c58 100644
--- a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
+++ b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
@@ -627,7 +627,7 @@ _cb_pageflip(int fd EINA_UNUSED, unsigned int frame 
EINA_UNUSED, unsigned int se
 
if (edata->ticking)
  {
-ecore_evas_animator_tick(ee, NULL);
+ecore_evas_animator_tick(ee, NULL, ecore_loop_time_get());
 ecore_drm2_fb_flip(NULL, edata->output);
  }
else if (ret) ecore_drm2_fb_flip(NULL, edata->output);

-- 

[EGIT] [core/efl] master 03/04: efl_ui_clock: fix use when no module is present.

[Cedric BAIL]

cedric pushed a commit to branch master.

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

commit 9f5c37cda744328f53b301572d0ea2b3842b2f39
Author: Cedric BAIL 
Date:   Mon Nov 14 11:22:39 2016 -0800

efl_ui_clock: fix use when no module is present.

T4875
---
 src/lib/elementary/efl_ui_clock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/lib/elementary/efl_ui_clock.c 
b/src/lib/elementary/efl_ui_clock.c
index 6c2d864..7a61acd 100644
--- a/src/lib/elementary/efl_ui_clock.c
+++ b/src/lib/elementary/efl_ui_clock.c
@@ -847,7 +847,8 @@ _ticker(void *data)
if (sd->curr_time.tm_sec > 0)
  {
 field = sd->field_list + EFL_UI_CLOCK_TYPE_SECOND;
-if (field->fmt_exist && field->visible)
+if (field->fmt_exist && field->visible &&
+dt_mod && dt_mod->field_value_display)
   dt_mod->field_value_display(sd->mod_data, field->item_obj);
  }
else

-- 

[EGIT] [core/efl] master 02/04: elementary: implement destructor in atspi mixin

[Lukasz Stanislawski]

cedric pushed a commit to branch master.

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

commit 93b509d66450418e66cf36ca06add65100f3afb2
Author: Lukasz Stanislawski 
Date:   Mon Nov 14 11:10:57 2016 -0800

elementary: implement destructor in atspi mixin

Summary:
Make atspi mixin inherit from Efl.Interface class and add Efl.Object
as it extensions class to gain acccess to destructor function.

This allow to better share code between implementations and avoid possible
mistakes during accessibilityt implementations.

Reviewers: cedric, jpeg, raster, kimcinoo

Subscribers: cedric, jpeg

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

Signed-off-by: Cedric BAIL 
---
 src/lib/elementary/elm_interface_atspi_accessible.c  | 11 +++
 src/lib/elementary/elm_interface_atspi_accessible.eo |  5 -
 src/lib/elementary/elm_widget.c  |  9 -
 3 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/src/lib/elementary/elm_interface_atspi_accessible.c 
b/src/lib/elementary/elm_interface_atspi_accessible.c
index 22afbaa..09ddea8 100644
--- a/src/lib/elementary/elm_interface_atspi_accessible.c
+++ b/src/lib/elementary/elm_interface_atspi_accessible.c
@@ -598,4 +598,15 @@ _elm_interface_atspi_accessible_type_set(Eo *obj, 
Elm_Interface_Atspi_Accessible
pd->type = val;
 }
 
+EOLIAN void
+_elm_interface_atspi_accessible_efl_object_destructor(Eo *obj, 
Elm_Interface_Atspi_Accessible_Data *pd)
+{
+   eina_stringshare_del(pd->name);
+   eina_stringshare_del(pd->description);
+   eina_stringshare_del(pd->translation_domain);
+   elm_atspi_relation_set_free(pd->relations);
+
+   efl_destructor(efl_super(obj, ELM_INTERFACE_ATSPI_ACCESSIBLE_MIXIN));
+}
+
 #include "elm_interface_atspi_accessible.eo.c"
diff --git a/src/lib/elementary/elm_interface_atspi_accessible.eo 
b/src/lib/elementary/elm_interface_atspi_accessible.eo
index 15a0c5a..5c5df21 100644
--- a/src/lib/elementary/elm_interface_atspi_accessible.eo
+++ b/src/lib/elementary/elm_interface_atspi_accessible.eo
@@ -235,7 +235,7 @@ struct Elm.Atspi.Relation
 
 type Elm.Atspi.Relation_Set: list; [[Elementary 
AT-SPI relation set type]]
 
-mixin Elm.Interface.Atspi_Accessible ()
+mixin Elm.Interface.Atspi_Accessible (Efl.Interface, Efl.Object)
 {
[[AT-SPI accessible mixin]]
eo_prefix: elm_interface_atspi_accessible;
@@ -432,6 +432,9 @@ mixin Elm.Interface.Atspi_Accessible ()
  }
   }
}
+   implements {
+  Efl.Object.destructor;
+   }
events {
   property,changed: string; [[Called when roperty has changed]]
   children,changed: Elm.Atspi.Event.Children_Changed.Data; [[Called when 
children have changed]]
diff --git a/src/lib/elementary/elm_widget.c b/src/lib/elementary/elm_widget.c
index f7f2def..5abcebf 100644
--- a/src/lib/elementary/elm_widget.c
+++ b/src/lib/elementary/elm_widget.c
@@ -4595,11 +4595,6 @@ _elm_widget_item_efl_object_destructor(Eo *eo_item, 
Elm_Widget_Item_Data *item)
  }
eina_hash_free(item->labels);
 
-   elm_interface_atspi_accessible_description_set(eo_item, NULL);
-   elm_interface_atspi_accessible_name_set(eo_item, NULL);
-   elm_interface_atspi_accessible_translation_domain_set(eo_item, NULL);
-   elm_interface_atspi_accessible_relationships_clear(eo_item);
-
elm_interface_atspi_accessible_removed(eo_item);
 
EINA_MAGIC_SET(item, EINA_MAGIC_NONE);
@@ -5853,10 +5848,6 @@ EOLIAN static void
 _elm_widget_efl_object_destructor(Eo *obj, Elm_Widget_Smart_Data *sd 
EINA_UNUSED)
 {
sd->on_destroy = EINA_TRUE;
-   elm_interface_atspi_accessible_description_set(obj, NULL);
-   elm_interface_atspi_accessible_name_set(obj, NULL);
-   elm_interface_atspi_accessible_translation_domain_set(obj, NULL);
-   elm_interface_atspi_accessible_relationships_clear(obj);
efl_destructor(efl_super(obj, ELM_WIDGET_CLASS));
sd->on_destroy = EINA_FALSE;
 

-- 

[EGIT] [core/efl] master 01/04: evas focus: Do not allow two objects focused by the same seat.

[Guilherme Iscaro]

cedric pushed a commit to branch master.

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

commit 883d41f0062b947c1d8793b5c6f9c586e20f484b
Author: Guilherme Iscaro 
Date:   Mon Nov 14 10:24:47 2016 -0800

evas focus: Do not allow two objects focused by the same seat.

Summary:
Before focusing an object, the intercept focus callback
is called. This callback may ask Evas to focus another object
instead, so it's necessary to check if the seat in question still
have a focused object event after a efl_canvas_object_seat_focus_del() call.

Reviewers: cedric, bdilly, barbieri, ProhtMeyhet, netstar

Subscribers: cedric, jpeg

Maniphest Tasks: T4864, T4886

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

Signed-off-by: Cedric BAIL 
---
 src/lib/evas/canvas/evas_focus.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/lib/evas/canvas/evas_focus.c b/src/lib/evas/canvas/evas_focus.c
index c09ba28..3245867 100644
--- a/src/lib/evas/canvas/evas_focus.c
+++ b/src/lib/evas/canvas/evas_focus.c
@@ -153,6 +153,9 @@ _efl_canvas_object_seat_focus_add(Eo *eo_obj,
if (current_focus)
  efl_canvas_object_seat_focus_del(current_focus, seat);
 
+   //In case intercept focus callback focused object we should return.
+   if (_current_focus_get(eo_obj, seat)) goto end;
+
efl_event_callback_add(seat, EFL_EVENT_DEL, _evas_focus_device_del_cb, obj);
 
obj->focused_by_seats = eina_list_append(obj->focused_by_seats, seat);

-- 

Re: [E-devel] [EGIT] [core/efl] master 07/12: docs: efl_network*: add missing documentation

[Gustavo Sverzut Barbieri]

Yeah, likely copy & pasta ;)

Em segunda-feira, 14 de novembro de 2016, Stefan Schmidt <
ste...@osg.samsung.com> escreveu:

> Hello.
>
> On 11/11/16 15:53, Gustavo Sverzut Barbieri wrote:
> > Efl_network won't be in our API, only efl_net. So don't worry
> >
>
> I go through all eo files right now. No matter if they are public API or
> not. And efl_network* had a lot more gaps to fill up compared to efl_net*
> :D
>
> I know that they are actively worked on right now but please take the
> extra two minutes to document all parts.
>
> Doing so I found a strange strange value name in:
>
> src/lib/ecore_con/efl_net_server_udp.eo line 103.
>
> The value is named loopback while the property itself is @property
> multicast_time_to_live. To me this looks like a multicast_loopback
> property copy and paste error. I would expect the value to be named ttl.
> Do you agree?
>
> I added a fixme while documenting but I guess raising it here has more
> chance of getting noticed.
>
> regards
> Stefan Schmidt
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [tools/clouseau] master 03/03: clouseau_data: use EET_COMPRESSION instead of EINA_TRUE

[Marcel Hollerbach]

bu5hm4n pushed a commit to branch master.

http://git.enlightenment.org/tools/clouseau.git/commit/?id=e53de2b36c911885fab3e59adcae849a7d6dfcb6

commit e53de2b36c911885fab3e59adcae849a7d6dfcb6
Author: Marcel Hollerbach 
Date:   Mon Nov 14 13:43:53 2016 +0100

clouseau_data: use EET_COMPRESSION instead of EINA_TRUE

even if its not a functional change, passing there a boolean value is
wrong, it requires a compression from the enumaration
---
 src/lib/clouseau_data.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/lib/clouseau_data.c b/src/lib/clouseau_data.c
index 3c639c7..74a7b83 100644
--- a/src/lib/clouseau_data.c
+++ b/src/lib/clouseau_data.c
@@ -675,9 +675,9 @@ clouseau_data_eet_info_save(const char *filename,
if (!fp) return EINA_FALSE;
 
eet_data_write(fp, clouseau_app_add_edd, CLOUSEAU_APP_ADD_ENTRY,
-  a, EINA_TRUE);
+  a, EET_COMPRESSION_DEFAULT);
eet_data_write(fp, clouseau_tree_data_edd, CLOUSEAU_TREE_DATA_ENTRY,
-  ftd, EINA_TRUE);
+  ftd, EET_COMPRESSION_DEFAULT);
 
/* Build list of (bmp_info_st *) according to user selection*/
EINA_LIST_FOREACH(ck_list, l , ck)
@@ -699,7 +699,7 @@ clouseau_data_eet_info_save(const char *filename,
 
 t.view = shots;
 eet_data_write(fp, clouseau_shot_list_edd, CLOUSEAU_BMP_LIST_ENTRY,
-   , EINA_TRUE);
+   , EET_COMPRESSION_DEFAULT);
 EINA_LIST_FREE(shots, st)
   {
  sprintf(buf, CLOUSEAU_BMP_DATA_ENTRY"/%llx", st->object);

-- 

[EGIT] [tools/clouseau] master 01/03: clouseau: lets bring back highlight in offline mode

[Marcel Hollerbach]

bu5hm4n pushed a commit to branch master.

http://git.enlightenment.org/tools/clouseau.git/commit/?id=9083738d1087486cb98e24ddf76dcd6c2a520e68

commit 9083738d1087486cb98e24ddf76dcd6c2a520e68
Author: Marcel Hollerbach 
Date:   Sun Nov 13 19:59:40 2016 +0100

clouseau: lets bring back highlight in offline mode

if the screenshot of a offline app is open it will be highlighted again.
The problem was that the highlight in the offline mode still worked with
legacy data which was not generated. Now this informations are just
searched from the Efl_Dbg_Info structs.

To test this you can just take a screenshot of a app, save the app with
the button in the upper right. Then start clouseau again in offline
mode, after that you can select a file. Select the file where you have
saved your app before. If you now display the screenshot and click on a
element, this object is displayed.
---
 src/bin/clouseau_client.c  | 90 +++
 src/lib/clouseau_app.c | 95 --
 src/lib/clouseau_data.c| 22 +++
 src/lib/clouseau_private.h |  4 +-
 4 files changed, 107 insertions(+), 104 deletions(-)

diff --git a/src/bin/clouseau_client.c b/src/bin/clouseau_client.c
index 8ea7990..8eb5f10 100644
--- a/src/bin/clouseau_client.c
+++ b/src/bin/clouseau_client.c
@@ -1313,6 +1313,63 @@ _connect_to_daemon(Gui_Elements *g)
 }
 
 static void
+_send_highlight(App_Data_St *app, Clouseau_Tree_Item *tree)
+{
+   if (!do_highlight)
+ return;
+
+   if (!eet_svr)
+ {
+//do offline highlight
+Efl_Dbg_Info *evas_object, *pos, *size, *x, *y, *w, *h;
+Eina_Rectangle r;
+Evas_Object *rectangle;
+bmp_info_st *bmp;
+Evas *e;
+
+evas_object = clouseau_eo_info_find(tree->new_eo_info , "Evas_Object");
+size = clouseau_eo_info_find(evas_object, "Size");
+pos = clouseau_eo_info_find(evas_object, "Position");
+
+#define FIND_AND_GET(c, name) \
+name = clouseau_eo_info_find(c, ""#name""); \
+eina_value_get(>value, );
+
+FIND_AND_GET(pos, x)
+FIND_AND_GET(pos, y)
+FIND_AND_GET(size, w)
+FIND_AND_GET(size, h)
+
+#undef FIND_AND_GET
+
+bmp = eina_list_search_unsorted(app->app->view,
+_bmp_app_ptr_cmp,
+(void*) (uintptr_t) app->td->app);
+
+if (!bmp)
+  {
+ printf("Error, failed to find window of open screenshot!\n");
+ return;
+  }
+
+//win is null as long as the screenshot is not displayed
+if (!bmp->win) return;
+e = efl_parent_get(bmp->win);
+rectangle = evas_object_rectangle_add(e);
+evas_object_geometry_set(rectangle, r.x, r.y, r.w, r.h);
+clouseau_data_object_highlight(rectangle);
+ }
+   else
+ {
+//sent highlight to the listening client
+highlight_st st = { (unsigned long long) (uintptr_t) app->app->ptr,
+tree->ptr };
+
+ecore_con_eet_send(eet_svr, CLOUSEAU_HIGHLIGHT_STR, );
+ }
+}
+
+static void
 _gl_selected(void *data, Evas_Object *pobj EINA_UNUSED, void *event_info)
 {
Gui_Elements *g = data;
@@ -1367,38 +1424,7 @@ _gl_selected(void *data, Evas_Object *pobj EINA_UNUSED, 
void *event_info)
   }
  }
 
-   if (!do_highlight)
- return;
-
-   /* START - replacing libclouseau_highlight(obj); */
-   app_info_st *app = g->sel_app->app;
-   highlight_st st = { (unsigned long long) (uintptr_t) app->ptr,
-   treeit->ptr };
-
-   if (eet_svr)
- {
-ecore_con_eet_send(eet_svr, CLOUSEAU_HIGHLIGHT_STR, );
- }
-
-   /* We also like to HIGHLIGHT on any app views that open (for offline) */
-   do
- {
-parent = prt;
-prt = elm_genlist_item_parent_get(prt);
- }
-   while (prt);
-
-   Clouseau_Tree_Item *t = elm_object_item_data_get(parent);
-   bmp_info_st *bmp = eina_list_search_unsorted(app->view,
- _bmp_object_ptr_cmp,
- (void*) (uintptr_t) t->ptr);
-
-   if (bmp && bmp->win)
- {  /* Third param gives evas surface when running offline */
-clouseau_data_object_highlight((void*) (uintptr_t) treeit->ptr,
-  >info->evas_props, bmp);
- }
-   /* END   - replacing clouseau_object_highlight(obj); */
+   _send_highlight(g->sel_app , treeit);
 }
 
 static void
diff --git a/src/lib/clouseau_app.c b/src/lib/clouseau_app.c
index c4e96fa..222d4a6 100644
--- a/src/lib/clouseau_app.c
+++ b/src/lib/clouseau_app.c
@@ -245,89 +245,38 @@ _clouseau_highlight_del(void *data,
ecore_animator_del(data);
 }
 
+
 EAPI void
-clouseau_data_object_highlight(Evas_Object *obj, Clouseau_Evas_Props *props, 
bmp_info_st *view)

[EGIT] [tools/clouseau] master 02/03: clouseau_data: use stream not file

[Marcel Hollerbach]

bu5hm4n pushed a commit to branch master.

http://git.enlightenment.org/tools/clouseau.git/commit/?id=e4628336220f3d3f23c4fe2b13734881ed81be1d

commit e4628336220f3d3f23c4fe2b13734881ed81be1d
Author: Marcel Hollerbach 
Date:   Mon Nov 14 13:41:46 2016 +0100

clouseau_data: use stream not file

if a Clouseau item is added via a function call stringshares are used.
To get the same allocation when reading the Clouseau item from the fs we
can use eina stream instead of eina file. This fixes T4888.
---
 src/lib/clouseau_data.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/lib/clouseau_data.c b/src/lib/clouseau_data.c
index 3dd1ba4..3c639c7 100644
--- a/src/lib/clouseau_data.c
+++ b/src/lib/clouseau_data.c
@@ -413,8 +413,8 @@ _clouseau_eo_descs_make(void)
eo_ptr_edd = clouseau_ptr_desc_make();
eo_double_edd = clouseau_double_desc_make();
 
-   EET_EINA_FILE_DATA_DESCRIPTOR_CLASS_SET(, Clouseau_Efl_Dbg_Info);
-   efl_dbg_info_edd = eet_data_descriptor_file_new();
+   EET_EINA_STREAM_DATA_DESCRIPTOR_CLASS_SET(, Clouseau_Efl_Dbg_Info);
+   efl_dbg_info_edd = eet_data_descriptor_stream_new();
EET_DATA_DESCRIPTOR_ADD_BASIC (efl_dbg_info_edd, Clouseau_Efl_Dbg_Info,
  "name", name, EET_T_STRING);
EET_DATA_DESCRIPTOR_ADD_BASIC (efl_dbg_info_edd, Clouseau_Efl_Dbg_Info,
@@ -427,7 +427,7 @@ _clouseau_eo_descs_make(void)
eddc.version = EET_DATA_DESCRIPTOR_CLASS_VERSION;
eddc.func.type_get = _dbg_info_union_type_get;
eddc.func.type_set = _dbg_info_union_type_set;
-   clouseau_union_edd = eet_data_descriptor_file_new();
+   clouseau_union_edd = eet_data_descriptor_stream_new();
 
EET_DATA_DESCRIPTOR_ADD_MAPPING(
  clouseau_union_edd, EFL_DBG_INFO_TYPE_STRING_STR

-- 

[EGIT] [core/efl] master 01/01: Eet: initialize descriptor class correctly

[Daniel Zaoui]

jackdanielz pushed a commit to branch master.

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

commit ee5a1d28f13f3f43737d31490f4b5428ce469dbe
Author: Daniel Zaoui 
Date:   Mon Nov 14 13:24:29 2016 +0200

Eet: initialize descriptor class correctly
---
 src/lib/eet/eet_data.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/lib/eet/eet_data.c b/src/lib/eet/eet_data.c
index 35ef7fb..cabafc3 100644
--- a/src/lib/eet/eet_data.c
+++ b/src/lib/eet/eet_data.c
@@ -1946,6 +1946,8 @@ 
eet_eina_stream_data_descriptor_class_set(Eet_Data_Descriptor_Class *eddc,
eddc->func.mem_free = _eet_mem_free;
eddc->func.str_alloc = (char *(*)(const char *))eina_stringshare_add;
eddc->func.str_free = eina_stringshare_del;
+   eddc->func.str_direct_alloc = NULL;
+   eddc->func.str_direct_free = NULL;
eddc->func.list_next = (void *(*)(void *))eina_list_next;
eddc->func.list_append = (void *(*)(void *, void *))eina_list_append;
eddc->func.list_data = (void *(*)(void *))eina_list_data_get;

-- 

[E-devel] FW: FW: FW: FW: Propose a Eina_Path

[Hermet Park]

Eina_Rectangle  => A data structure.
Evas_Rectangle => A drawing primitive.

Sorry, but I thought rect is a bit digressed to this topic.

I'm not a negative even though path is not going in Eina.

But let's consider more realitic position.

I think path is unlike to an interface but it's more to be an individual data 
set.

And efl_gfx_shape is likely to depend on this.

If you agree that it could be an interface, then efl_gfx_path may be also fine.

but not in ector/evas because efl interface is lower than them.

-Original Message-
From: "Andrew Williams" 
To: "Enlightenment developer list"; 
Cc: 
Sent: 2016-11-14 (월) 17:51:31
Subject: Re: [E-devel] FW: FW: FW: Propose a Eina_Path
 
I think that even if a shape is not going to be rendered it is still a
graphical concept.
In most frameworks I can find it is in a graphics, geometry or gui
namespace.

Eina is already becoming ambiguous in its purpose and adding shapes in
there seems confusing.

Is it just me who is confused that Eina_Rectangle and Evas_Rect both exist?

Andy
On Mon, 14 Nov 2016 at 02:16, Hermet Park  wrote:

> elm_path well..  it's not a concreted idea yet, but we may provide that
> kind of feasible object like a elm_flip for an arbitrary shaped objects.
>
> I don't know about elm_chart but guess it does not have a simliar concept
> with path object.
> Because the traditional charts have been designed for a sort of vector
> wise graphical drawing like lines, bars and *pizza* pies etc.
> but this path is majorly designed  for binding our graphcial objects onto
> an arbitrary path.
>
> See the next some screenshots.
>
> https://phab.enlightenment.org/F48119
> https://phab.enlightenment.org/F48120
> https://phab.enlightenment.org/F48121
> https://phab.enlightenment.org/F48122
>
> If you have more than the chart idea than I expected then please share it
> to us.
>
> Also, I don't see extending efl_gfx_shape is not the answer here.
> If path object is introduced in elm, path won't need all shape stuff.
> Even some usage may just require only path data without graphical drawing.
> So rather than that, modulization(divide path) should be considerd for
> shape now.
>
> Honestly, I'm not quite sure which place is the best for the path
> interface but at least Eina for now.
> Even necessary of path eo binding. of course, path naming could be
> considered in case of Eina.
>
>
> -Original Message-
> From: "Cedric BAIL"
> To: "e-devel";
> Cc:
> Sent: 2016-11-12 (토) 01:41:58
> Subject: Re: [E-devel] FW: FW: Propose a Eina_Path
>
> On Nov 11, 2016 04:39, "Andrew Williams"  wrote:
> >
> > It strange that eina defines a rectangle and no other shapes - is that
> even
> > used outside a graphical context?
>
>
> Eina started as a simple toolset and got a lot of stuff that was just
> refactoring of our stack. We have a tiler and rectangle along with matrix,
> just from the top of my head. I clearly see the need for having a path
> primitive, the question is where and under what name. It would be fine in
> eina, if not for the name that is confusing. It would be fine in Ector, if
> not for Ector depending on efl_gfx_shape. Thinking of it, for binding, we
> want this API to be in Eo. So why not extending efl_gfx_shape to provide
> what it is missing and have elementary use it.
>
>
> Added question what is the goal of elm_path object ? I am personnally
> looking forward to an elm_chart object a lot more.
>
>
> Best,
>
>   Cedric
>
>
> > A
> > On Fri, 11 Nov 2016 at 11:17, Hermet Park  wrote:
> >
> > > Thanks for your advice.
> > >
> > > But imo, it's unlike to graphical one such as evas_rect and
> evas_line...
> > > Path itself is more likely to the eina_rect...
> > > Because path itself is just data information.
> > > Also, efl_gfx_shape should rely on it.
> > >
> > > -Original Message-
> > > From: "Andrew Williams"
> > > To: "Enlightenment developer list"<
> > > enlightenment-devel@lists.sourceforge.net>;
> > > Cc:
> > > Sent: 2016-11-11 (금) 20:07:44
> > > Subject: Re: [E-devel] FW: Propose a Eina_Path
> > >
> > > Alongside Evas_Rect and Evas_Line?
> > >
> > > On Fri, 11 Nov 2016 at 08:59, Hermet Park  wrote:
> > >
> > > > Yes, but I have no idea about proper place than eina atm.
> > > >
> > > > I feel like It's more close to an data structure & utility function
> than
> > > > interface.
> > > >
> > > > Any idea?
> > > >
> > > > -Original Message-
> > > > From: "Andrew Williams"
> > > > To: "Enlightenment developer list"<
> > > > enlightenment-devel@lists.sourceforge.net>;
> > > > Cc:
> > > > Sent: 2016-11-11 (금) 17:31:04
> > > > Subject: Re: [E-devel] Propose a Eina_Path
> > > >
> > > > The name makes sense in a graphical context. Therefore if it can be
> > > > somewhere less 

[E-devel] Weekly news from the automated build and QA front

[Stefan Schmidt]

Hello.

Summary:
o Fairly calm week in terms of changes here.
o Coverity catched up on EFL as well now and we got 8 new defects. If 
you added some code lately please have a look and see if they found 
issues in your code and fix them.


This should give everyone an overview over what has happened in the last
week on the QA front. The numbers in parentheses reflect the values from
last week to give you a trend.

CI:
o Overall build statistic: 8.11% (6.27%) failed.
https://build.enlightenment.org/

Unit tests:
o N/A (N/A) unit tests for efl

Coverage:
o EFL total coverage is at N/A (N/A) lines, N/A (N/A) functions and N/A 
(N/A) branches
https://build.enlightenment.org/view/Test%20Coverage/

Coverity:
o EFL: Outstanding defects 93 (85) with a density of 0.08 (0.08)
o Enlightenment: Outstanding defects 1 (6) with a density of 0 (0.02)
o Terminology: Outstanding defects 0 (1) with a density of 0 (0.01)
o Rage: Outstanding defects 0 (0) with a density of 0 (0)

Phab:
o EFL bug count: 297 (294)
o E bug count: 388 (394)
https://phab.enlightenment.org/maniphest/report/burn/
o Pending patch reviews: 102 (104)

regards
Stefan Schmidt

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EDD 2017 location discussion - Vote opened

[Stefan Schmidt]

Hello.

On 04/11/16 11:48, Stefan Schmidt wrote:
> Hello.
>
> After gettign more feedback and proposals here I put out a vote:
>
> https://phab.enlightenment.org/V27
>
> Let us know what makes sense to you!

We got feedback and preferences form 15 people so far which is great and 
already gives a direction. (e.g. Paris, Toulouse and Edinburgh are 
leading with Malta directly behind)

This community is bigger than 15 people though. :) If you have not voted 
yet please do so to help us understand where we should focus on.

regards
Stefan Schmidt

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 07/12: docs: efl_network*: add missing documentation

[Stefan Schmidt]

Hello.

On 11/11/16 15:53, Gustavo Sverzut Barbieri wrote:
> Efl_network won't be in our API, only efl_net. So don't worry
>

I go through all eo files right now. No matter if they are public API or 
not. And efl_network* had a lot more gaps to fill up compared to efl_net* :D

I know that they are actively worked on right now but please take the 
extra two minutes to document all parts.

Doing so I found a strange strange value name in:

src/lib/ecore_con/efl_net_server_udp.eo line 103.

The value is named loopback while the property itself is @property 
multicast_time_to_live. To me this looks like a multicast_loopback 
property copy and paste error. I would expect the value to be named ttl. 
Do you agree?

I added a fixme while documenting but I guess raising it here has more 
chance of getting noticed.

regards
Stefan Schmidt

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL packaging on Debian

[Stefan Schmidt]

Hello.

On 11/11/16 14:34, Ross Vandegrift wrote:
> On Thu, Nov 10, 2016 at 11:06:04AM +0100, Stefan Schmidt wrote:
>> I did my monthly packaging update again and was hoping this moved to
>> unstable by now. It is still in experimental only as far as I can see.
>> Is there an automatic way this packages get from experimental to
>> unstable, testing stable? Or are you supposed to pursue Albin again to
>> get it uploaded to unstable?
>
> A few items on the current status:
>
> 1) All uploads will go through Albin (or some other sponsor).
>
> While reviewing, Albin had some questions on the internal EFL deps and
> shared symbol versioning.  The packaging produces unusually strict (for
> Debian) dependencies.  We're working through it.
>
> 2) experimental -> unstable is a manual migration.  Once in unstable,
> packages automatically migrate to testing, and then to the next stable
> release.  Packages are not normally added to existing stable releases.


Ah, I see. I somehow expected it to be an automatic process from 
experimental to unstable as well. Thus I was wondering why nothing 
happened in one months. If its a manual process that makes more sense.

>
> We uploaded to experimental for additional testing opportunity, since
> Debian contains packages which depend on EFL.  When we're happy with the
> status, they'll be uploaded to unstable.
>
> 3) The packages in experimental break binary compatability with the
> existing unstable packages.  For instance, you can't use the
> experimental packages break the terminology packages in unstable.
>
> (Why?  The packages in unstable preserve a bit of pre-1.0 eina ABI that
> was released into Debian many years ago.  That requires disabling magic
> debug, and in EFL 1.17 tests break with this config.  We decided the
> eina tests are more valuable than the ancient ABI.)
>
> So it's going to take some time - sorry.

Oki doki. I will wait and hope :)

regards
Stefan Schmidt

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Schedule discussion for 1.19

[Stefan Schmidt]

Hello.

On 14/11/16 02:55, Gyuyoung Kim wrote:
> Hello Stefan,
>
> I wanna start to prepare EWebKit 1.19 version soon. Please let me know when
> EFL 1.19 candidate is prepared.
>
> I will make EWebKit 1.19 based on the candidates.

Great to hear!

We have not finalized the 1.19 schedule yet. The dates you quoted are 
now longer valid. The most likely target for 1.19 is February right now. 
So you have time to relax :)

I will let you know when the schedule gets final.

regards
Stefan Schmidt

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FW: FW: FW: Propose a Eina_Path

[Andrew Williams]

I think that even if a shape is not going to be rendered it is still a
graphical concept.
In most frameworks I can find it is in a graphics, geometry or gui
namespace.

Eina is already becoming ambiguous in its purpose and adding shapes in
there seems confusing.

Is it just me who is confused that Eina_Rectangle and Evas_Rect both exist?

Andy
On Mon, 14 Nov 2016 at 02:16, Hermet Park  wrote:

> elm_path well..  it's not a concreted idea yet, but we may provide that
> kind of feasible object like a elm_flip for an arbitrary shaped objects.
>
> I don't know about elm_chart but guess it does not have a simliar concept
> with path object.
> Because the traditional charts have been designed for a sort of vector
> wise graphical drawing like lines, bars and *pizza* pies etc.
> but this path is majorly designed  for binding our graphcial objects onto
> an arbitrary path.
>
> See the next some screenshots.
>
> https://phab.enlightenment.org/F48119
> https://phab.enlightenment.org/F48120
> https://phab.enlightenment.org/F48121
> https://phab.enlightenment.org/F48122
>
> If you have more than the chart idea than I expected then please share it
> to us.
>
> Also, I don't see extending efl_gfx_shape is not the answer here.
> If path object is introduced in elm, path won't need all shape stuff.
> Even some usage may just require only path data without graphical drawing.
> So rather than that, modulization(divide path) should be considerd for
> shape now.
>
> Honestly, I'm not quite sure which place is the best for the path
> interface but at least Eina for now.
> Even necessary of path eo binding. of course, path naming could be
> considered in case of Eina.
>
>
> -Original Message-
> From: "Cedric BAIL"
> To: "e-devel";
> Cc:
> Sent: 2016-11-12 (토) 01:41:58
> Subject: Re: [E-devel] FW: FW: Propose a Eina_Path
>
> On Nov 11, 2016 04:39, "Andrew Williams"  wrote:
> >
> > It strange that eina defines a rectangle and no other shapes - is that
> even
> > used outside a graphical context?
>
>
> Eina started as a simple toolset and got a lot of stuff that was just
> refactoring of our stack. We have a tiler and rectangle along with matrix,
> just from the top of my head. I clearly see the need for having a path
> primitive, the question is where and under what name. It would be fine in
> eina, if not for the name that is confusing. It would be fine in Ector, if
> not for Ector depending on efl_gfx_shape. Thinking of it, for binding, we
> want this API to be in Eo. So why not extending efl_gfx_shape to provide
> what it is missing and have elementary use it.
>
>
> Added question what is the goal of elm_path object ? I am personnally
> looking forward to an elm_chart object a lot more.
>
>
> Best,
>
>   Cedric
>
>
> > A
> > On Fri, 11 Nov 2016 at 11:17, Hermet Park  wrote:
> >
> > > Thanks for your advice.
> > >
> > > But imo, it's unlike to graphical one such as evas_rect and
> evas_line...
> > > Path itself is more likely to the eina_rect...
> > > Because path itself is just data information.
> > > Also, efl_gfx_shape should rely on it.
> > >
> > > -Original Message-
> > > From: "Andrew Williams"
> > > To: "Enlightenment developer list"<
> > > enlightenment-devel@lists.sourceforge.net>;
> > > Cc:
> > > Sent: 2016-11-11 (금) 20:07:44
> > > Subject: Re: [E-devel] FW: Propose a Eina_Path
> > >
> > > Alongside Evas_Rect and Evas_Line?
> > >
> > > On Fri, 11 Nov 2016 at 08:59, Hermet Park  wrote:
> > >
> > > > Yes, but I have no idea about proper place than eina atm.
> > > >
> > > > I feel like It's more close to an data structure & utility function
> than
> > > > interface.
> > > >
> > > > Any idea?
> > > >
> > > > -Original Message-
> > > > From: "Andrew Williams"
> > > > To: "Enlightenment developer list"<
> > > > enlightenment-devel@lists.sourceforge.net>;
> > > > Cc:
> > > > Sent: 2016-11-11 (금) 17:31:04
> > > > Subject: Re: [E-devel] Propose a Eina_Path
> > > >
> > > > The name makes sense in a graphical context. Therefore if it can be
> > > > somewhere less general than Eina then it could make sense.
> > > >
> > > > Andy
> > > >
> > > > On Fri, 11 Nov 2016 at 08:00, Gustavo Sverzut Barbieri <
> > > barbi...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Em sexta-feira, 11 de novembro de 2016, Hermet Park <
> > > her...@hermet.pe.kr
> > > > >
> > > > > escreveu:
> > > > >
> > > > > > Hello everyone.
> > > > > >
> > > > > > Currently, I'm trying a prototype - Path Object  using the evas
> map.
> > > > > > (specifically for a scenario, text on path).
> > > > > > It looks nice if it works on gl backend. (i will share the result
> > > > later)
> > > > > >
> > > > > > But before we talk about path object stuff, I wanna propose a
> > > > Eina_Path.
> > > > > >
> > > > > > After reviewed efl_gfx_shape interface