Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Apologies. I misquoted who the patch is from. It is actually from Alex Wu -Original Message- From: Enlightenment SVN [mailto:no-re...@enlightenment.org] Sent: 01 August 2012 15:15 To: enlightenment-...@lists.sourceforge.net Subject: E SVN: devilhorns trunk/evas/src/lib/canvas Log: Evas: Fix trying to clip objects to the framespace clip if the object is going to be deleted. Patch from eduardo.de.barros.l...@intel.com. Author: devilhorns Date: 2012-08-01 07:14:34 -0700 (Wed, 01 Aug 2012) New Revision: 74739 Trac: http://trac.enlightenment.org/e/changeset/74739 Modified: trunk/evas/src/lib/canvas/evas_render.c Modified: trunk/evas/src/lib/canvas/evas_render.c === --- trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 13:32:38 UTC (rev 74738) +++ trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 14:14:34 UTC (rev 74739) @@ -1392,6 +1392,8 @@ } } +if (obj->delete_me) continue; + EINA_RECTANGLE_SET(&clip_rect, e->framespace.clip->cur.geometry.x, e->framespace.clip->cur.geometry.y, -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-svn mailing list enlightenment-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
* Enlightenment SVN [2012-08-01 07:14:35 -0700]: > Log: > Evas: Fix trying to clip objects to the framespace clip if the object > is going to be deleted. Patch from eduardo.de.barros.l...@intel.com. > > > > Author: devilhorns > Date: 2012-08-01 07:14:34 -0700 (Wed, 01 Aug 2012) > New Revision: 74739 > Trac: http://trac.enlightenment.org/e/changeset/74739 > > Modified: > trunk/evas/src/lib/canvas/evas_render.c > > Modified: trunk/evas/src/lib/canvas/evas_render.c > === > --- trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 13:32:38 UTC (rev > 74738) > +++ trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 14:14:34 UTC (rev > 74739) > @@ -1392,6 +1392,8 @@ > } >} > > +if (obj->delete_me) continue; > + Did you bother to build it? > EINA_RECTANGLE_SET(&clip_rect, > e->framespace.clip->cur.geometry.x, > e->framespace.clip->cur.geometry.y, > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Hahaha, sorry, I did not. Just caught it now in my build Will fix. -Original Message- From: Gustavo Lima Chaves [mailto:gl...@profusion.mobi] Sent: 01 August 2012 15:27 To: enlightenment-devel@lists.sourceforge.net Cc: enlightenment-...@lists.sourceforge.net Subject: Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas * Enlightenment SVN [2012-08-01 07:14:35 -0700]: > Log: > Evas: Fix trying to clip objects to the framespace clip if the object > is going to be deleted. Patch from eduardo.de.barros.l...@intel.com. > > > > Author: devilhorns > Date: 2012-08-01 07:14:34 -0700 (Wed, 01 Aug 2012) > New Revision: 74739 > Trac: http://trac.enlightenment.org/e/changeset/74739 > > Modified: > trunk/evas/src/lib/canvas/evas_render.c > > Modified: trunk/evas/src/lib/canvas/evas_render.c > === > --- trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 13:32:38 UTC (rev 74738) > +++ trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 14:14:34 UTC (rev 74739) > @@ -1392,6 +1392,8 @@ > } >} > > +if (obj->delete_me) continue; > + Did you bother to build it? > EINA_RECTANGLE_SET(&clip_rect, > e->framespace.clip->cur.geometry.x, > e->framespace.clip->cur.geometry.y, > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
changelog
Vincent
On Mon, Sep 3, 2012 at 11:41 AM, Enlightenment SVN
wrote:
> Log:
> Evas: When doing a move or geometry_get, we need to make sure that we
> don't try to do these on the framespace clip object. Also, since we
> need the evas to get the framespace clip object, just directly use the
> framespace values from the canvas, rather than function call to get
> those values.
>
>
>
> Author: devilhorns
> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> New Revision: 75989
> Trac: http://trac.enlightenment.org/e/changeset/75989
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_main.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:39:30
> UTC (rev 75988)
> +++ trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:41:01
> UTC (rev 75989)
> @@ -590,6 +590,7 @@
> EAPI void
> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
> {
> + Evas *evas;
> int is, was = 0, pass = 0, freeze = 0;
> int nx = 0, ny = 0;
>
> @@ -601,16 +602,14 @@
> nx = x;
> ny = y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
>{
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - nx += fx;
> - ny += fy;
> + nx += evas->framespace.x;
> + ny += evas->framespace.y;
>}
> }
>
> @@ -749,6 +748,7 @@
> EAPI void
> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
> *y, Evas_Coord *w, Evas_Coord *h)
> {
> + Evas *evas;
> int nx = 0, ny = 0;
>
> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
> @@ -764,16 +764,14 @@
> nx = obj->cur.geometry.x;
> ny = obj->cur.geometry.y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
>{
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - if (nx > 0) nx -= fx;
> - if (ny > 0) ny -= fy;
> + if (nx > 0) nx -= evas->framespace.x;
> + if (ny > 0) ny -= evas->framespace.y;
>}
> }
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Fixed.
-Original Message-
From: Vincent Torri [mailto:vincent.to...@gmail.com]
Sent: 03 September 2012 11:08
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
changelog
Vincent
On Mon, Sep 3, 2012 at 11:41 AM, Enlightenment SVN
wrote:
> Log:
> Evas: When doing a move or geometry_get, we need to make sure that we
> don't try to do these on the framespace clip object. Also, since we
> need the evas to get the framespace clip object, just directly use the
> framespace values from the canvas, rather than function call to get
> those values.
>
>
>
> Author: devilhorns
> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> New Revision: 75989
> Trac: http://trac.enlightenment.org/e/changeset/75989
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_main.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03
09:39:30 UTC (rev 75988)
> +++ trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03
09:41:01 UTC (rev 75989)
> @@ -590,6 +590,7 @@
> EAPI void
> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y) {
> + Evas *evas;
> int is, was = 0, pass = 0, freeze = 0;
> int nx = 0, ny = 0;
>
> @@ -601,16 +602,14 @@
> nx = x;
> ny = y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
>{
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - nx += fx;
> - ny += fy;
> + nx += evas->framespace.x;
> + ny += evas->framespace.y;
>}
> }
>
> @@ -749,6 +748,7 @@
> EAPI void
> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x,
> Evas_Coord *y, Evas_Coord *w, Evas_Coord *h) {
> + Evas *evas;
> int nx = 0, ny = 0;
>
> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ); @@ -764,16 +764,14 @@
> nx = obj->cur.geometry.x;
> ny = obj->cur.geometry.y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
>{
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - if (nx > 0) nx -= fx;
> - if (ny > 0) ny -= fy;
> + if (nx > 0) nx -= evas->framespace.x;
> + if (ny > 0) ny -= evas->framespace.y;
>}
> }
>
>
>
> --
>
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Seriously, all this frame space thing feels out if place.
Realistically speaking, anything but elementary should manage it. The code is
simplified as the only place would have to do with it is elm_win and 99% of the
cases it's automatically fixed by getting "elm_win_resize_object_add" right.
I'm against this frame space since the first version, see my comment comparing
that to EWS. Everyday I see more and more commits like this one that makes my
original complaints being right
--Gustavo
Sent from my iPhone
On 03/09/2012, at 06:41, "Enlightenment SVN" wrote:
> Log:
> Evas: When doing a move or geometry_get, we need to make sure that we
> don't try to do these on the framespace clip object. Also, since we
> need the evas to get the framespace clip object, just directly use the
> framespace values from the canvas, rather than function call to get
> those values.
>
>
>
> Author: devilhorns
> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> New Revision: 75989
> Trac: http://trac.enlightenment.org/e/changeset/75989
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_main.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:39:30 UTC
> (rev 75988)
> +++ trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:41:01 UTC
> (rev 75989)
> @@ -590,6 +590,7 @@
> EAPI void
> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
> {
> + Evas *evas;
>int is, was = 0, pass = 0, freeze = 0;
>int nx = 0, ny = 0;
>
> @@ -601,16 +602,14 @@
>nx = x;
>ny = y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
> {
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - nx += fx;
> - ny += fy;
> + nx += evas->framespace.x;
> + ny += evas->framespace.y;
> }
> }
>
> @@ -749,6 +748,7 @@
> EAPI void
> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
> *y, Evas_Coord *w, Evas_Coord *h)
> {
> + Evas *evas;
>int nx = 0, ny = 0;
>
>MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
> @@ -764,16 +764,14 @@
>nx = obj->cur.geometry.x;
>ny = obj->cur.geometry.y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
> {
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - if (nx > 0) nx -= fx;
> - if (ny > 0) ny -= fy;
> + if (nx > 0) nx -= evas->framespace.x;
> + if (ny > 0) ny -= evas->framespace.y;
> }
> }
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Well if u r fishing for an argument (which i suspect is the case) then u are
out of luck. I refuse to get sucked into this debate. Take it up with the
wayland people who made it so that all client apps in wayland must draw their
own borders.
dh
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Gustavo Sverzut Barbieri wrote:
Seriously, all this frame space thing feels out if place.
Realistically speaking, anything but elementary should manage it. The code is
simplified as the only place would have to do with it is elm_win and 99% of the
cases it's automatically fixed by getting "elm_win_resize_object_add" right.
I'm against this frame space since the first version, see my comment comparing
that to EWS. Everyday I see more and more commits like this one that makes my
original complaints being right
--Gustavo
Sent from my iPhone
On 03/09/2012, at 06:41, "Enlightenment SVN" wrote:
> Log:
> Evas: When doing a move or geometry_get, we need to make sure that we
> don't try to do these on the framespace clip object. Also, since we
> need the evas to get the framespace clip object, just directly use the
> framespace values from the canvas, rather than function call to get
> those values.
>
>
>
> Author: devilhorns
> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> New Revision: 75989
> Trac: http://trac.enlightenment.org/e/changeset/75989
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_main.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
>_
> --- trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:39:30 UTC (rev
> 75988)
> +++ trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:41:01 UTC (rev
> 75989)
> @@ -590,6 +590,7 @@
> EAPI void
> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
> {
> + Evas *evas;
> int is, was = 0, pass = 0, freeze = 0;
> int nx = 0, ny = 0;
>
> @@ -601,16 +602,14 @@
> nx = x;
> ny = y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
> {
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> - &fx, &fy, NULL, NULL);
> - nx += fx;
> - ny += fy;
> + nx += evas->framespace.x;
> + ny += evas->framespace.y;
> }
> }
>
> @@ -749,6 +748,7 @@
> EAPI void
> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
> *y, Evas_Coord *w, Evas_Coord *h)
> {
> + Evas *evas;
> int nx = 0, ny = 0;
>
> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
> @@ -764,16 +764,14 @@
> nx = obj->cur.geometry.x;
> ny = obj->cur.geometry.y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
> {
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> - &fx, &fy, NULL, NULL);
> - if (nx > 0) nx -= fx;
> - if (ny > 0) ny -= fy;
> + if (nx > 0) nx -= evas->framespace.x;
> + if (ny > 0) ny -= evas->framespace.y;
> }
> }
>
>
>
>_
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
_
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Hey devilhorns,
Didn't you agree that the framespace stuff should be outside of Evas,
and just inside Elementary? I remember that last week you talked on
irc about having a patch available for that, so I can only understand
that you and Gustavo are not discussing about the same thing.
And I also agree that all of this should go outside of Evas, handled
only by elm_win.
On Mon, Sep 3, 2012 at 2:21 PM, Christopher Michael
wrote:
> Well if u r fishing for an argument (which i suspect is the case) then u are
> out of luck. I refuse to get sucked into this debate. Take it up with the
> wayland people who made it so that all client apps in wayland must draw their
> own borders.
>
> dh
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> Gustavo Sverzut Barbieri wrote:
>
> Seriously, all this frame space thing feels out if place.
>
> Realistically speaking, anything but elementary should manage it. The code is
> simplified as the only place would have to do with it is elm_win and 99% of
> the cases it's automatically fixed by getting "elm_win_resize_object_add"
> right.
>
> I'm against this frame space since the first version, see my comment
> comparing that to EWS. Everyday I see more and more commits like this one
> that makes my original complaints being right
>
> --Gustavo
>
> Sent from my iPhone
>
> On 03/09/2012, at 06:41, "Enlightenment SVN"
> wrote:
>
>> Log:
>> Evas: When doing a move or geometry_get, we need to make sure that we
>> don't try to do these on the framespace clip object. Also, since we
>> need the evas to get the framespace clip object, just directly use the
>> framespace values from the canvas, rather than function call to get
>> those values.
>>
>>
>>
>> Author: devilhorns
>> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
>> New Revision: 75989
>> Trac: http://trac.enlightenment.org/e/changeset/75989
>>
>> Modified:
>> trunk/evas/src/lib/canvas/evas_object_main.c
>>
>> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
>>_
>
>> --- trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:39:30 UTC
>> (rev 75988)
>> +++ trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:41:01 UTC
>> (rev 75989)
>> @@ -590,6 +590,7 @@
>> EAPI void
>> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
>> {
>> + Evas *evas;
>> int is, was = 0, pass = 0, freeze = 0;
>> int nx = 0, ny = 0;
>>
>> @@ -601,16 +602,14 @@
>> nx = x;
>> ny = y;
>>
>> - if (!obj->is_frame)
>> + evas = obj->layer->evas;
>> +
>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>> {
>> if ((!obj->smart.parent) && (obj->smart.smart))
>> {
>> - int fx, fy;
>> -
>> - evas_output_framespace_get(obj->layer->evas,
>> - &fx, &fy, NULL, NULL);
>> - nx += fx;
>> - ny += fy;
>> + nx += evas->framespace.x;
>> + ny += evas->framespace.y;
>> }
>> }
>>
>> @@ -749,6 +748,7 @@
>> EAPI void
>> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
>> *y, Evas_Coord *w, Evas_Coord *h)
>> {
>> + Evas *evas;
>> int nx = 0, ny = 0;
>>
>> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
>> @@ -764,16 +764,14 @@
>> nx = obj->cur.geometry.x;
>> ny = obj->cur.geometry.y;
>>
>> - if (!obj->is_frame)
>> + evas = obj->layer->evas;
>> +
>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>> {
>> if ((!obj->smart.parent) && (obj->smart.smart))
>> {
>> - int fx, fy;
>> -
>> - evas_output_framespace_get(obj->layer->evas,
>> - &fx, &fy, NULL, NULL);
>> - if (nx > 0) nx -= fx;
>> - if (ny > 0) ny -= fy;
>> + if (nx > 0) nx -= evas->framespace.x;
>> + if (ny > 0) ny -= evas->framespace.y;
>> }
>> }
>>
>>
>>
>>_
>
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>_
>
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> _
>
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _
>
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat lan
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Just found them on my backlog, both patches are here:
http://pastebin.com/vJnQbxG4
http://pastebin.com/pdd6aV2Q
Which seems to be exactly that, except that there are still some other
things still being done with framespace inside Evas, for example
inside evas_render.c.
On Mon, Sep 3, 2012 at 4:03 PM, Rafael Antognolli
wrote:
> Hey devilhorns,
>
> Didn't you agree that the framespace stuff should be outside of Evas,
> and just inside Elementary? I remember that last week you talked on
> irc about having a patch available for that, so I can only understand
> that you and Gustavo are not discussing about the same thing.
>
> And I also agree that all of this should go outside of Evas, handled
> only by elm_win.
>
> On Mon, Sep 3, 2012 at 2:21 PM, Christopher Michael
> wrote:
>> Well if u r fishing for an argument (which i suspect is the case) then u are
>> out of luck. I refuse to get sucked into this debate. Take it up with the
>> wayland people who made it so that all client apps in wayland must draw
>> their own borders.
>>
>> dh
>>
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>> Gustavo Sverzut Barbieri wrote:
>>
>> Seriously, all this frame space thing feels out if place.
>>
>> Realistically speaking, anything but elementary should manage it. The code
>> is simplified as the only place would have to do with it is elm_win and 99%
>> of the cases it's automatically fixed by getting "elm_win_resize_object_add"
>> right.
>>
>> I'm against this frame space since the first version, see my comment
>> comparing that to EWS. Everyday I see more and more commits like this one
>> that makes my original complaints being right
>>
>> --Gustavo
>>
>> Sent from my iPhone
>>
>> On 03/09/2012, at 06:41, "Enlightenment SVN"
>> wrote:
>>
>>> Log:
>>> Evas: When doing a move or geometry_get, we need to make sure that we
>>> don't try to do these on the framespace clip object. Also, since we
>>> need the evas to get the framespace clip object, just directly use the
>>> framespace values from the canvas, rather than function call to get
>>> those values.
>>>
>>>
>>>
>>> Author: devilhorns
>>> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
>>> New Revision: 75989
>>> Trac: http://trac.enlightenment.org/e/changeset/75989
>>>
>>> Modified:
>>> trunk/evas/src/lib/canvas/evas_object_main.c
>>>
>>> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
>>>_
>>
>>> --- trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:39:30 UTC
>>> (rev 75988)
>>> +++ trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:41:01 UTC
>>> (rev 75989)
>>> @@ -590,6 +590,7 @@
>>> EAPI void
>>> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
>>> {
>>> + Evas *evas;
>>> int is, was = 0, pass = 0, freeze = 0;
>>> int nx = 0, ny = 0;
>>>
>>> @@ -601,16 +602,14 @@
>>> nx = x;
>>> ny = y;
>>>
>>> - if (!obj->is_frame)
>>> + evas = obj->layer->evas;
>>> +
>>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>>> {
>>> if ((!obj->smart.parent) && (obj->smart.smart))
>>> {
>>> - int fx, fy;
>>> -
>>> - evas_output_framespace_get(obj->layer->evas,
>>> - &fx, &fy, NULL, NULL);
>>> - nx += fx;
>>> - ny += fy;
>>> + nx += evas->framespace.x;
>>> + ny += evas->framespace.y;
>>> }
>>> }
>>>
>>> @@ -749,6 +748,7 @@
>>> EAPI void
>>> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
>>> *y, Evas_Coord *w, Evas_Coord *h)
>>> {
>>> + Evas *evas;
>>> int nx = 0, ny = 0;
>>>
>>> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
>>> @@ -764,16 +764,14 @@
>>> nx = obj->cur.geometry.x;
>>> ny = obj->cur.geometry.y;
>>>
>>> - if (!obj->is_frame)
>>> + evas = obj->layer->evas;
>>> +
>>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>>> {
>>> if ((!obj->smart.parent) && (obj->smart.smart))
>>> {
>>> - int fx, fy;
>>> -
>>> - evas_output_framespace_get(obj->layer->evas,
>>> - &fx, &fy, NULL, NULL);
>>> - if (nx > 0) nx -= fx;
>>> - if (ny > 0) ny -= fy;
>>> + if (nx > 0) nx -= evas->framespace.x;
>>> + if (ny > 0) ny -= evas->framespace.y;
>>> }
>>> }
>>>
>>>
>>>
>>>_
>>
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>_
>>
>>> enlightenment-svn mailing list
>>> enlightenment-...@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
>> _
>>
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security a
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 03/09/2012 07:03 PM, Rafael Antognolli wrote:
> Hey devilhorns,
>
> Didn't you agree that the framespace stuff should be outside of Evas,
> and just inside Elementary? I remember that last week you talked on
> irc about having a patch available for that, so I can only understand
> that you and Gustavo are not discussing about the same thing.
Yea, that was my stance originally...or rather, that was my
preference... Except that it cannot be done only inside Elementary. In
an ideal world yes, but what happens if someone creates an application
which does not use Elementary ? Just uses a bare ecore_evas.. then their
objects would not be drawing correctly (read: the could potentially be
drawn below the frame). So, in order to support older applications (or
applications made using Base EFL, not Elm), we have to handle it in Evas.
dh
>
> And I also agree that all of this should go outside of Evas, handled
> only by elm_win.
>
> On Mon, Sep 3, 2012 at 2:21 PM, Christopher Michael
> wrote:
>> Well if u r fishing for an argument (which i suspect is the case) then u are
>> out of luck. I refuse to get sucked into this debate. Take it up with the
>> wayland people who made it so that all client apps in wayland must draw
>> their own borders.
>>
>> dh
>>
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>> Gustavo Sverzut Barbieri wrote:
>>
>> Seriously, all this frame space thing feels out if place.
>>
>> Realistically speaking, anything but elementary should manage it. The code
>> is simplified as the only place would have to do with it is elm_win and 99%
>> of the cases it's automatically fixed by getting "elm_win_resize_object_add"
>> right.
>>
>> I'm against this frame space since the first version, see my comment
>> comparing that to EWS. Everyday I see more and more commits like this one
>> that makes my original complaints being right
>>
>> --Gustavo
>>
>> Sent from my iPhone
>>
>> On 03/09/2012, at 06:41, "Enlightenment SVN"
>> wrote:
>>
>>> Log:
>>> Evas: When doing a move or geometry_get, we need to make sure that we
>>> don't try to do these on the framespace clip object. Also, since we
>>> need the evas to get the framespace clip object, just directly use the
>>> framespace values from the canvas, rather than function call to get
>>> those values.
>>>
>>>
>>>
>>> Author: devilhorns
>>> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
>>> New Revision: 75989
>>> Trac: http://trac.enlightenment.org/e/changeset/75989
>>>
>>> Modified:
>>> trunk/evas/src/lib/canvas/evas_object_main.c
>>>
>>> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
>>> _
>>
>>> --- trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:39:30 UTC
>>> (rev 75988)
>>> +++ trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:41:01 UTC
>>> (rev 75989)
>>> @@ -590,6 +590,7 @@
>>> EAPI void
>>> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
>>> {
>>> + Evas *evas;
>>> int is, was = 0, pass = 0, freeze = 0;
>>> int nx = 0, ny = 0;
>>>
>>> @@ -601,16 +602,14 @@
>>> nx = x;
>>> ny = y;
>>>
>>> - if (!obj->is_frame)
>>> + evas = obj->layer->evas;
>>> +
>>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>>> {
>>> if ((!obj->smart.parent) && (obj->smart.smart))
>>> {
>>> - int fx, fy;
>>> -
>>> - evas_output_framespace_get(obj->layer->evas,
>>> - &fx, &fy, NULL, NULL);
>>> - nx += fx;
>>> - ny += fy;
>>> + nx += evas->framespace.x;
>>> + ny += evas->framespace.y;
>>> }
>>> }
>>>
>>> @@ -749,6 +748,7 @@
>>> EAPI void
>>> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
>>> *y, Evas_Coord *w, Evas_Coord *h)
>>> {
>>> + Evas *evas;
>>> int nx = 0, ny = 0;
>>>
>>> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
>>> @@ -764,16 +764,14 @@
>>> nx = obj->cur.geometry.x;
>>> ny = obj->cur.geometry.y;
>>>
>>> - if (!obj->is_frame)
>>> + evas = obj->layer->evas;
>>> +
>>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>>> {
>>> if ((!obj->smart.parent) && (obj->smart.smart))
>>> {
>>> - int fx, fy;
>>> -
>>> - evas_output_framespace_get(obj->layer->evas,
>>> - &fx, &fy, NULL, NULL);
>>> - if (nx > 0) nx -= fx;
>>> - if (ny > 0) ny -= fy;
>>> + if (nx > 0) nx -= evas->framespace.x;
>>> + if (ny > 0) ny -= evas->framespace.y;
>>> }
>>> }
>>>
>>>
>>>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Mon, 3 Sep 2012 13:42:09 -0300 Gustavo Sverzut Barbieri
said:
> Seriously, all this frame space thing feels out if place.
>
> Realistically speaking, anything but elementary should manage it. The code is
> simplified as the only place would have to do with it is elm_win and 99% of
> the cases it's automatically fixed by getting "elm_win_resize_object_add"
> right.
>
> I'm against this frame space since the first version, see my comment
> comparing that to EWS. Everyday I see more and more commits like this one
> that makes my original complaints being right
if you don't have framespace - wayland BREAKS applications and compatibility.
of course you love to break things as often as possible. it doesn't matter that
regular widget stuff breaks or doesn't break, it's apps that then decide to
place widgets or objects manually that break. imagine you made a space invaders
game. you place objects starting at 0, 0 which is below your titlebar.. but now
they are over/under the titlebar when near the top. this is a break.
> --Gustavo
>
> Sent from my iPhone
>
> On 03/09/2012, at 06:41, "Enlightenment SVN"
> wrote:
>
> > Log:
> > Evas: When doing a move or geometry_get, we need to make sure that we
> > don't try to do these on the framespace clip object. Also, since we
> > need the evas to get the framespace clip object, just directly use the
> > framespace values from the canvas, rather than function call to get
> > those values.
> >
> >
> >
> > Author: devilhorns
> > Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> > New Revision: 75989
> > Trac: http://trac.enlightenment.org/e/changeset/75989
> >
> > Modified:
> > trunk/evas/src/lib/canvas/evas_object_main.c
> >
> > Modified: trunk/evas/src/lib/canvas/evas_object_main.c
> > ===
> > --- trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:39:30 UTC
> > (rev 75988) +++ trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03
> > 09:41:01 UTC (rev 75989) @@ -590,6 +590,7 @@
> > EAPI void
> > evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
> > {
> > + Evas *evas;
> >int is, was = 0, pass = 0, freeze = 0;
> >int nx = 0, ny = 0;
> >
> > @@ -601,16 +602,14 @@
> >nx = x;
> >ny = y;
> >
> > - if (!obj->is_frame)
> > + evas = obj->layer->evas;
> > +
> > + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> > {
> > if ((!obj->smart.parent) && (obj->smart.smart))
> > {
> > - int fx, fy;
> > -
> > - evas_output_framespace_get(obj->layer->evas,
> > -&fx, &fy, NULL, NULL);
> > - nx += fx;
> > - ny += fy;
> > + nx += evas->framespace.x;
> > + ny += evas->framespace.y;
> > }
> > }
> >
> > @@ -749,6 +748,7 @@
> > EAPI void
> > evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
> > *y, Evas_Coord *w, Evas_Coord *h) {
> > + Evas *evas;
> >int nx = 0, ny = 0;
> >
> >MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
> > @@ -764,16 +764,14 @@
> >nx = obj->cur.geometry.x;
> >ny = obj->cur.geometry.y;
> >
> > - if (!obj->is_frame)
> > + evas = obj->layer->evas;
> > +
> > + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> > {
> > if ((!obj->smart.parent) && (obj->smart.smart))
> > {
> > - int fx, fy;
> > -
> > - evas_output_framespace_get(obj->layer->evas,
> > -&fx, &fy, NULL, NULL);
> > - if (nx > 0) nx -= fx;
> > - if (ny > 0) ny -= fy;
> > + if (nx > 0) nx -= evas->framespace.x;
> > + if (ny > 0) ny -= evas->framespace.y;
> > }
> > }
> >
> >
> >
> > --
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sou
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Mon, 03 Sep 2012 20:19:20 + Christopher Michael wrote: > On 03/09/2012 07:03 PM, Rafael Antognolli wrote: > > Hey devilhorns, > > > > Didn't you agree that the framespace stuff should be outside of > > Evas, and just inside Elementary? I remember that last week you > > talked on irc about having a patch available for that, so I can > > only understand that you and Gustavo are not discussing about the > > same thing. > > Yea, that was my stance originally...or rather, that was my > preference... Except that it cannot be done only inside Elementary. > In an ideal world yes, but what happens if someone creates an > application which does not use Elementary ? Just uses a bare > ecore_evas.. then their objects would not be drawing correctly (read: > the could potentially be drawn below the frame). So, in order to > support older applications (or applications made using Base EFL, not > Elm), we have to handle it in Evas. I'm still not sure if I want to use Elementary for things, though I'm giving it a try in an unimportant project. I've not looked much at Wayland yet, but it sounds like a good idea in general. Hope it's implemented well, and not just by us, but by the Wayland people. Also Lua stuff, which I intend to write more backend support for when I get some time, is below the Elementary level, it's edje level stuff. I can see people writing Lua edje proggies that don't use Elementary. I intend to write some real examples like that. -- 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 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 04/09/12 05:39, David Seikel wrote: > On Mon, 03 Sep 2012 20:19:20 + Christopher Michael > wrote: > >> On 03/09/2012 07:03 PM, Rafael Antognolli wrote: >>> Hey devilhorns, >>> >>> Didn't you agree that the framespace stuff should be outside of >>> Evas, and just inside Elementary? I remember that last week you >>> talked on irc about having a patch available for that, so I can >>> only understand that you and Gustavo are not discussing about the >>> same thing. >> >> Yea, that was my stance originally...or rather, that was my >> preference... Except that it cannot be done only inside Elementary. >> In an ideal world yes, but what happens if someone creates an >> application which does not use Elementary ? Just uses a bare >> ecore_evas.. then their objects would not be drawing correctly (read: >> the could potentially be drawn below the frame). So, in order to >> support older applications (or applications made using Base EFL, not >> Elm), we have to handle it in Evas. > > I'm still not sure if I want to use Elementary for things, though I'm > giving it a try in an unimportant project. I've not looked much at > Wayland yet, but it sounds like a good idea in general. Hope it's > implemented well, and not just by us, but by the Wayland people. > I suppose that is a subjective statement really ;) One persons version of "implemented well" may not match anothers ;) > Also Lua stuff, which I intend to write more backend support for when I > get some time, is below the Elementary level, it's edje level stuff. I > can see people writing Lua edje proggies that don't use Elementary. I > intend to write some real examples like that. > Well, if/when you do, if you find issues in using Lua under Wayland, please report them :) Cheers, dh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, 04 Sep 2012 07:19:58 +0100 Christopher Michael wrote: > On 04/09/12 05:39, David Seikel wrote: > > On Mon, 03 Sep 2012 20:19:20 + Christopher Michael > > wrote: > > > >> On 03/09/2012 07:03 PM, Rafael Antognolli wrote: > >>> Hey devilhorns, > >>> > >>> Didn't you agree that the framespace stuff should be outside of > >>> Evas, and just inside Elementary? I remember that last week you > >>> talked on irc about having a patch available for that, so I can > >>> only understand that you and Gustavo are not discussing about the > >>> same thing. > >> > >> Yea, that was my stance originally...or rather, that was my > >> preference... Except that it cannot be done only inside Elementary. > >> In an ideal world yes, but what happens if someone creates an > >> application which does not use Elementary ? Just uses a bare > >> ecore_evas.. then their objects would not be drawing correctly > >> (read: the could potentially be drawn below the frame). So, in > >> order to support older applications (or applications made using > >> Base EFL, not Elm), we have to handle it in Evas. > > > > I'm still not sure if I want to use Elementary for things, though > > I'm giving it a try in an unimportant project. I've not looked > > much at Wayland yet, but it sounds like a good idea in general. > > Hope it's implemented well, and not just by us, but by the Wayland > > people. > > > I suppose that is a subjective statement really ;) One persons > version of "implemented well" may not match anothers ;) > > > Also Lua stuff, which I intend to write more backend support for > > when I get some time, is below the Elementary level, it's edje > > level stuff. I can see people writing Lua edje proggies that don't > > use Elementary. I intend to write some real examples like that. > > > > Well, if/when you do, if you find issues in using Lua under Wayland, > please report them :) I'll know who to spank, er I mean report problems to. B-) Seems that the consensus on the other thread is to stick with keeping the Wayland frame stuff in evas and transparent to apps, so I doubt if it will be a problem for me. -- 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 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 04/09/12 07:31, David Seikel wrote: > On Tue, 04 Sep 2012 07:19:58 +0100 Christopher Michael > wrote: > >> On 04/09/12 05:39, David Seikel wrote: >>> On Mon, 03 Sep 2012 20:19:20 + Christopher Michael >>> wrote: >>> On 03/09/2012 07:03 PM, Rafael Antognolli wrote: > Hey devilhorns, > > Didn't you agree that the framespace stuff should be outside of > Evas, and just inside Elementary? I remember that last week you > talked on irc about having a patch available for that, so I can > only understand that you and Gustavo are not discussing about the > same thing. Yea, that was my stance originally...or rather, that was my preference... Except that it cannot be done only inside Elementary. In an ideal world yes, but what happens if someone creates an application which does not use Elementary ? Just uses a bare ecore_evas.. then their objects would not be drawing correctly (read: the could potentially be drawn below the frame). So, in order to support older applications (or applications made using Base EFL, not Elm), we have to handle it in Evas. >>> >>> I'm still not sure if I want to use Elementary for things, though >>> I'm giving it a try in an unimportant project. I've not looked >>> much at Wayland yet, but it sounds like a good idea in general. >>> Hope it's implemented well, and not just by us, but by the Wayland >>> people. >>> >> I suppose that is a subjective statement really ;) One persons >> version of "implemented well" may not match anothers ;) >> >>> Also Lua stuff, which I intend to write more backend support for >>> when I get some time, is below the Elementary level, it's edje >>> level stuff. I can see people writing Lua edje proggies that don't >>> use Elementary. I intend to write some real examples like that. >>> >> >> Well, if/when you do, if you find issues in using Lua under Wayland, >> please report them :) > > I'll know who to spank, er I mean report problems to. B-) > Hahahaha :) You can see that bullseye painted on my back from there huh ? :) > Seems that the consensus on the other thread is to stick with keeping > the Wayland frame stuff in evas and transparent to apps, so I doubt if > it will be a problem for me. > It's really the only way to sanely do it. Well, that was the goal...to be as transparent as possible and not have to require a bunch of changes on the application side. When all is said and done, you should not have any problems (assuming you are doing nothing engine specific in your app). dh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, 04 Sep 2012 07:40:30 +0100 Christopher Michael wrote: > On 04/09/12 07:31, David Seikel wrote: > > On Tue, 04 Sep 2012 07:19:58 +0100 Christopher Michael > > wrote: > > > >> On 04/09/12 05:39, David Seikel wrote: > >>> On Mon, 03 Sep 2012 20:19:20 + Christopher Michael > >>> wrote: > >>> > On 03/09/2012 07:03 PM, Rafael Antognolli wrote: > > Hey devilhorns, > > > > Didn't you agree that the framespace stuff should be outside of > > Evas, and just inside Elementary? I remember that last week you > > talked on irc about having a patch available for that, so I can > > only understand that you and Gustavo are not discussing about > > the same thing. > > Yea, that was my stance originally...or rather, that was my > preference... Except that it cannot be done only inside > Elementary. In an ideal world yes, but what happens if someone > creates an application which does not use Elementary ? Just uses > a bare ecore_evas.. then their objects would not be drawing > correctly (read: the could potentially be drawn below the > frame). So, in order to support older applications (or > applications made using Base EFL, not Elm), we have to handle it > in Evas. > >>> > >>> I'm still not sure if I want to use Elementary for things, though > >>> I'm giving it a try in an unimportant project. I've not looked > >>> much at Wayland yet, but it sounds like a good idea in general. > >>> Hope it's implemented well, and not just by us, but by the Wayland > >>> people. > >>> > >> I suppose that is a subjective statement really ;) One persons > >> version of "implemented well" may not match anothers ;) > >> > >>> Also Lua stuff, which I intend to write more backend support for > >>> when I get some time, is below the Elementary level, it's edje > >>> level stuff. I can see people writing Lua edje proggies that > >>> don't use Elementary. I intend to write some real examples like > >>> that. > >>> > >> > >> Well, if/when you do, if you find issues in using Lua under > >> Wayland, please report them :) > > > > I'll know who to spank, er I mean report problems to. B-) > > > > Hahahaha :) You can see that bullseye painted on my back from there > huh ? :) /me hides the can of paint and the still dripping paint brush. Er, um, what bullseye painted on your back? > > Seems that the consensus on the other thread is to stick with > > keeping the Wayland frame stuff in evas and transparent to apps, so > > I doubt if it will be a problem for me. > > > It's really the only way to sanely do it. Well, that was the > goal...to be as transparent as possible and not have to require a > bunch of changes on the application side. When all is said and done, > you should not have any problems (assuming you are doing nothing > engine specific in your app). Yep, that's what I want to see, cross platform transparency. Saves me from having to worry about it. B-) -- 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 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 04/09/12 07:48, David Seikel wrote: > On Tue, 04 Sep 2012 07:40:30 +0100 Christopher Michael > wrote: > >> On 04/09/12 07:31, David Seikel wrote: >>> On Tue, 04 Sep 2012 07:19:58 +0100 Christopher Michael >>> wrote: >>> On 04/09/12 05:39, David Seikel wrote: > On Mon, 03 Sep 2012 20:19:20 + Christopher Michael > wrote: > >> On 03/09/2012 07:03 PM, Rafael Antognolli wrote: >>> Hey devilhorns, >>> >>> Didn't you agree that the framespace stuff should be outside of >>> Evas, and just inside Elementary? I remember that last week you >>> talked on irc about having a patch available for that, so I can >>> only understand that you and Gustavo are not discussing about >>> the same thing. >> >> Yea, that was my stance originally...or rather, that was my >> preference... Except that it cannot be done only inside >> Elementary. In an ideal world yes, but what happens if someone >> creates an application which does not use Elementary ? Just uses >> a bare ecore_evas.. then their objects would not be drawing >> correctly (read: the could potentially be drawn below the >> frame). So, in order to support older applications (or >> applications made using Base EFL, not Elm), we have to handle it >> in Evas. > > I'm still not sure if I want to use Elementary for things, though > I'm giving it a try in an unimportant project. I've not looked > much at Wayland yet, but it sounds like a good idea in general. > Hope it's implemented well, and not just by us, but by the Wayland > people. > I suppose that is a subjective statement really ;) One persons version of "implemented well" may not match anothers ;) > Also Lua stuff, which I intend to write more backend support for > when I get some time, is below the Elementary level, it's edje > level stuff. I can see people writing Lua edje proggies that > don't use Elementary. I intend to write some real examples like > that. > Well, if/when you do, if you find issues in using Lua under Wayland, please report them :) >>> >>> I'll know who to spank, er I mean report problems to. B-) >>> >> >> Hahahaha :) You can see that bullseye painted on my back from there >> huh ? :) > > /me hides the can of paint and the still dripping paint brush. > > Er, um, what bullseye painted on your back? > LMAO :) >>> Seems that the consensus on the other thread is to stick with >>> keeping the Wayland frame stuff in evas and transparent to apps, so >>> I doubt if it will be a problem for me. >>> >> It's really the only way to sanely do it. Well, that was the >> goal...to be as transparent as possible and not have to require a >> bunch of changes on the application side. When all is said and done, >> you should not have any problems (assuming you are doing nothing >> engine specific in your app). > > Yep, that's what I want to see, cross platform transparency. Saves me > from having to worry about it. B-) > Indeed :) That's the idea ;) App developers won't have to worry about if their app will function in Wayland (assuming they have coded generically). dh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 05/25/2012 02:55 PM, Enlightenment SVN wrote: > Log: > Evas: Fix clipping issue for wayland engines (were drawing outside the >viewort). This fixes the Elm Map 3D test issue where the cube was >drawing onto the window border (and perhaps other tests). > > > > Author: devilhorns > Date: 2012-05-25 05:55:45 -0700 (Fri, 25 May 2012) > New Revision: 71426 > Trac: http://trac.enlightenment.org/e/changeset/71426 > > Modified: >trunk/evas/src/lib/canvas/evas_render.c > > + if ((!strcmp(e->engine.module->definition->name, "wayland_shm")) || > + (!strcmp(e->engine.module->definition->name, "wayland_egl"))) strncmp(e->...->name, "wayland", 7)? S. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, Jul 3, 2012 at 4:30 AM, Enlightenment SVN wrote: > Log: > Evas: Merge evas_object_image changes from Tizen to upstream EFL. > > > > Author: devilhorns dh, this patch touches highly sensible parts of evas. Next time you integrate a commit as such, please split the cosmetic/whitespace/reindent/rewrap into different patches than the actual changes. It was super annoying to review this, and maybe something passed unnoticed because of this mess. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, Jul 3, 2012 at 4:30 AM, Enlightenment SVN wrote: > Log: > Evas: Merge evas_object_image changes from Tizen to upstream EFL. > > > > Author: devilhorns >dh, this patch touches highly sensible parts of evas. Next time you >integrate a commit as such, please split the >cosmetic/whitespace/reindent/rewrap into different patches than the >actual changes. >It was super annoying to review this, and maybe something passed >unnoticed because of this mess. Are you looking at a different commit here or something ? Because I just looked at this commit again, and I find nothing in there that is hard to read or annoying. If this commit annoyed you, I'm sorry. Perhaps I should just run every commit through you first to make sure you are not going to get annoyed by it ? I get annoyed by commits all the time, but you don't see me making mountains out of molehills. Anyone else feeling the need to jump on the bandwagon here ? If so, speak now. Getting a bit tired of all this nonsense so if you want to say something, now is the time so we can all get off our high horses and move forward. dh -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbieri@... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, Jul 3, 2012 at 2:26 PM, wrote:
> On Tue, Jul 3, 2012 at 4:30 AM, Enlightenment SVN
> wrote:
>> Log:
>> Evas: Merge evas_object_image changes from Tizen to upstream EFL.
>>
>>
>>
>> Author: devilhorns
>
>>dh, this patch touches highly sensible parts of evas. Next time you
>>integrate a commit as such, please split the
>>cosmetic/whitespace/reindent/rewrap into different patches than the
>>actual changes.
>
>>It was super annoying to review this, and maybe something passed
>>unnoticed because of this mess.
> Are you looking at a different commit here or something ? Because I just
> looked at this commit again, and I find nothing in there that is hard to read
> or annoying.
> If this commit annoyed you, I'm sorry. Perhaps I should just run every commit
> through you first to make sure you are not going to get annoyed by it ? I get
> annoyed by commits all the time, but you don't see me making mountains out of
> molehills.
> Anyone else feeling the need to jump on the bandwagon here ? If so, speak
> now. Getting a bit tired of all this nonsense so if you want to say
> something, now is the time so we can all get off our high horses and move
> forward.
Looking at the first part of the commit:
- o->engine_data =
obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output,
-
o->engine_data,
- 0,
- &data,
-
&o->load_error);
- return evas_object_image_data_convert_internal(o, data, to_cspace);
+ o->engine_data =
+
obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output,
+ o->engine_data, 0, &data,
+ &o->load_error);
this is pure cosmetic. But who knows? Needs to investigate because right after:
+ result = evas_object_image_data_convert_internal(o, data, to_cspace);
+ if (o->engine_data)
+ {
+o->engine_data =
+
obj->layer->evas->engine.func->image_data_put(obj->layer->evas->engine.data.output,
+o->engine_data, data);
+ }
which may impact something.
If it was clear that the first one was just cosmetic and split into
another patch, we could ignore it and just look at the relevant
changes.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
From: "Gustavo Sverzut Barbieri"
To: "Enlightenment developer list"
Sent: Tuesday, July 3, 2012 7:13:02 PM
Subject: Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, Jul 3, 2012 at 2:26 PM, wrote:
> On Tue, Jul 3, 2012 at 4:30 AM, Enlightenment SVN
> wrote:
>> Log:
>> Evas: Merge evas_object_image changes from Tizen to upstream EFL.
>>
>>
>>
>> Author: devilhorns
>
>>dh, this patch touches highly sensible parts of evas. Next time you
>>integrate a commit as such, please split the
>>cosmetic/whitespace/reindent/rewrap into different patches than the
>>actual changes.
>
>>It was super annoying to review this, and maybe something passed
>>unnoticed because of this mess.
> Are you looking at a different commit here or something ? Because I just
> looked at this commit again, and I find nothing in there that is hard to read
> or annoying.
> If this commit annoyed you, I'm sorry. Perhaps I should just run every commit
> through you first to make sure you are not going to get annoyed by it ? I get
> annoyed by commits all the time, but you don't see me making mountains out of
> molehills.
> Anyone else feeling the need to jump on the bandwagon here ? If so, speak
> now. Getting a bit tired of all this nonsense so if you want to say
> something, now is the time so we can all get off our high horses and move
> forward.
Looking at the first part of the commit:
- o->engine_data =
obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output,
-
o->engine_data,
- 0,
- &data,
-
&o->load_error);
- return evas_object_image_data_convert_internal(o, data, to_cspace);
+ o->engine_data =
+
obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output,
+ o->engine_data, 0, &data,
+ &o->load_error);
this is pure cosmetic. But who knows? Needs to investigate because right after:
+ result = evas_object_image_data_convert_internal(o, data, to_cspace);
+ if (o->engine_data)
+ {
+ o->engine_data =
+
obj->layer->evas->engine.func->image_data_put(obj->layer->evas->engine.data.output,
+ o->engine_data, data);
+ }
which may impact something.
If it was clear that the first one was just cosmetic and split into
another patch, we could ignore it and just look at the relevant
changes.
And the relevant changes can still be viewed in the same patch above ... I am
not seeing the problem here. If you read the patch and see that something is a
cosmetic change, then just read over it and go "ok, that's a cosmetic change, I
can ignore that" and move on.
dh
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Sun, 9 Aug 2009, Enlightenment SVN wrote:
> Log:
> Formatting
>
> Author: devilhorns
> Date: 2009-08-09 09:41:51 -0700 (Sun, 09 Aug 2009)
> New Revision: 41648
>
> Modified:
> trunk/evas/src/lib/canvas/evas_render.c
>
> Modified: trunk/evas/src/lib/canvas/evas_render.c
> ===
> --- trunk/evas/src/lib/canvas/evas_render.c 2009-08-09 15:47:44 UTC (rev
> 41647)
> +++ trunk/evas/src/lib/canvas/evas_render.c 2009-08-09 16:41:51 UTC (rev
> 41648)
> @@ -298,7 +298,8 @@
> }
> }
>
> -Eina_Bool pending_change(void *data, __UNUSED__ void *gdata)
> +Eina_Bool
> +pending_change(void *data, __UNUSED__ void *gdata)
> {
>Evas_Object *obj;
and put __UNUSED__ after the variable :-)
Vincent
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Vincent,
Not entirely sure what you are saying here. All I did was fix the
formatting.
dh
Vincent Torri wrote:
>
> On Sun, 9 Aug 2009, Enlightenment SVN wrote:
>
>> Log:
>> Formatting
>>
>> Author: devilhorns
>> Date: 2009-08-09 09:41:51 -0700 (Sun, 09 Aug 2009)
>> New Revision: 41648
>>
>> Modified:
>> trunk/evas/src/lib/canvas/evas_render.c
>>
>> Modified: trunk/evas/src/lib/canvas/evas_render.c
>> ===
>> --- trunk/evas/src/lib/canvas/evas_render.c 2009-08-09 15:47:44 UTC (rev
>> 41647)
>> +++ trunk/evas/src/lib/canvas/evas_render.c 2009-08-09 16:41:51 UTC (rev
>> 41648)
>> @@ -298,7 +298,8 @@
>> }
>> }
>>
>> -Eina_Bool pending_change(void *data, __UNUSED__ void *gdata)
>> +Eina_Bool
>> +pending_change(void *data, __UNUSED__ void *gdata)
>> {
>>Evas_Object *obj;
>
> and put __UNUSED__ after the variable :-)
>
> Vincent
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
> Not entirely sure what you are saying here. All I did was fix the formatting. >>> -pending_change(void *data, __UNUSED__ void *gdata) >>> +pending_change(void *data, void *gdata __UNUSED__) Vincent -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Thought that's what you meant...just wanted to be sure. Thanks :) dh Vincent Torri wrote: > >> Not entirely sure what you are saying here. All I did was fix the >> formatting. > -pending_change(void *data, __UNUSED__ void *gdata) > +pending_change(void *data, void *gdata __UNUSED__) > > Vincent > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
