Re: [E-devel] Clipped Smart Object draft
On Tue, May 20, 2008 at 12:10 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: Anyone else looked at this? May I add the clipped smart object (no layout stuff!) to evas? I can add some docs and even change basic smart object to refer to this one for simple implementations. For those who are irc challenged, maybe you could give a short overview of what it is this is supposed to help address, why it should be 'added' to evas, etc. :) It's just a way to help implementation of smart objects. Most common use smart objectcase: create an internal clipper, clip every child to it, move will move children relatively to parent, clip/clip_unset/color/show/hide will all go to the internal clipper. Resize is undefined. What this code provide is this set of default method implementation and an easy to extend base class, just do like in the examples and provide your own methods (be it constructor or resize or show... you name it), which can call the parent. I exposed all the base methods to make it easier to use, one can override show() to do fancy stuff and still call the original to do real work, this could be done differently, having users to copy (ie: parent_class) Smart_Class after evas_object_smart_clipped_smart_set() Why should it be added to Evas: because it's very simple, it's useful and can serve as base for other things. Actually the idea of such component was born while I was teaching INdT guys and after documenting that you should always do the same stuff for most of methods I opted to add such default implementation and errors went down by a huge factor... actually nowadays it's hard to find a good case to use plain smart object itself. Al, one of things that I failed to figure in the past why show, hide, color_set, clip_set and color_set are ALL marked as DELETE ME. I don't remember for sure, but I think it was rephorm that did say that the common use case is like that and maybe these methods would be replaced with this default implementation only. So it's a good thing in that direction. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
We decided to improve the line implementation to speed up the use of
evas-lines in python (our case). Yes, we could just use polygons, but we are
trying to reduce processor usage at this point.
Its faster to draw lines (with lines implementation) directly, specially
dealing with vertical/horizontal/45 deg. lines.
Calculating where points of polygons must be drawn relative to width of line
in python-side is a lost of processing too.
Being faster, simpler and without breaking any compatibility, I dont know
why Lines should not to have width support. Specially thinking about how
simpler it makes to work with Lines.
Yes, the code may be optimized, but its working fine and fast here.
Greetings,
Diego B. Contezini
On Sun, May 18, 2008 at 11:51 PM, The Rasterman Carsten Haitzler
[EMAIL PROTECTED] wrote:
On Tue, 13 May 2008 17:20:27 -0300 Diego Bitencourt Contezini
[EMAIL PROTECTED] babbled:
any reason you didnt just use polygons? :)
Hello all.
Working with evas+Lines in python, is fast. But if you need a line with
more
then one pixel of width, it gets very slow (in dispositives like N800),
because object Line dont have width support, so its needen to use
Rectangles
to make it works.
I made a modification to support width in Lines object. It is composed by
3
patchs.
*First*, in evas/lib/*, it changes internal call to engine line drawer,
inserting more one argument to the same function. It is a callback, so,
no
modification is needen in any engine module that dosnt support Lines with
more then 1 pixel (they will just draw with only 1 pixel). Has added new
functions to deal with width, without breaking any compatibility of other
functions.
*Second*, in evas/engine/software16 to add support to width.
*Third,* in python-evas binding, to add support to use the modifications
made in evas.
If anyone get any bug or suggest any modification to patch, im a
listener.
Thanks all
Diego Bitencourt Contezini
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
--- evas-0.9.9.042/src/lib/canvas/evas_object_line.c 2008-05-07 17:22:34.0 -0300
+++ evas-linha/src/lib/canvas/evas_object_line.c 2008-05-20 09:50:03.0 -0300
@@ -18,6 +18,7 @@
} object;
} cache;
Evas_Coord x1, y1, x2, y2;
+ int width;
} cur, prev;
void *engine_data;
@@ -86,7 +87,6 @@
evas_object_inject(obj, e);
return obj;
}
-
/**
* Sets the coordinates of the end points of the given evas line object.
* @param obj The given evas line object.
@@ -143,12 +143,12 @@
obj-cur.geometry.y = min_y;
obj-cur.geometry.w = max_x - min_x + 2.0;
obj-cur.geometry.h = max_y - min_y + 2.0;
- obj-cur.cache.geometry.validity = 0;
o-cur.x1 = x1 - min_x;
o-cur.y1 = y1 - min_y;
o-cur.x2 = x2 - min_x;
o-cur.y2 = y2 - min_y;
o-changed = 1;
+ o-cur.width = 1;
evas_object_change(obj);
evas_object_coords_recalc(obj);
if (obj-layer-evas-events_frozen = 0)
@@ -171,6 +171,122 @@
}
/**
+ * Sets the coordinates of the end points of the given evas line object with width param.
+ * @param objThe given evas line object.
+ * @param x1 The X coordinate of the first point.
+ * @param y1 The Y coordinate of the first point.
+ * @param x2 The X coordinate of the second point.
+ * @param y2 The Y coordinate of the second point.
+ * @param width The width of the line.
+ * @ingroup Evas_Line_Group
+ */
+EAPI void
+evas_object_line_xyw_set(Evas_Object *obj, Evas_Coord x1, Evas_Coord y1, Evas_Coord x2, Evas_Coord y2, int width)
+{
+ Evas_Object_Line *o;
+ Evas_Coord min_x, max_x, min_y, max_y;
+ int is, was = 0;
+
+ MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
+ return;
+ MAGIC_CHECK_END();
+ o = (Evas_Object_Line *)(obj-object_data);
+ MAGIC_CHECK(o, Evas_Object_Line, MAGIC_OBJ_LINE);
+ return;
+ MAGIC_CHECK_END();
+ if ((x1 == o-cur.x1) (y1 == o-cur.y1)
+ (x2 == o-cur.x2) (y2 == o-cur.y2)) return;
+
+ if (obj-layer-evas-events_frozen = 0)
+ {
+ if (!evas_event_passes_through(obj))
+ was = evas_object_is_in_output_rect(obj,
+ obj-layer-evas-pointer.x,
+ obj-layer-evas-pointer.y, 1, 1);
+ }
+
+ if (x1 x2)
+ {
+ min_x = x1;
+ max_x = x2;
+ }
+ else
+ {
+ min_x = x2;
+ max_x = x1;
+ }
+
+ if (y1 y2)
+ {
+ min_y = y1;
+ max_y = y2;
+ }
+ else
+ {
+ min_y = y2;
+ max_y = y1;
+ }
+
+ if(width 1)
+ {
+ int tsum; // type of Sum (x = 0, y = 1)
+ if(x1 == x2)
+ { // vertical line
+ if(y1 == y2)
+ tsum = 1;
+ else
+ tsum = 0;
+ } else if(y1 == y2) // horizontal line
+ tsum = 1;
+ else if((max_x - min_x) (max_y - min_y)) // dx dy
+ tsum = 1;
+ else // dx = dy
+ tsum = 0;
+
+ if(tsum 0)
+ {
+ min_y -= (width/2)+1 - width%2;
+ max_y += (width/2);
+ }
+ else
+ {
+ min_x -=
Re: [E-devel] Line + width support.
This patches I sent last mail are the last working, sorry, I forgot to tell. They are with two corrections we've got here in testing. Diego - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Missing mouse up event, when opening a pointer grabbing window
Carsten Haitzler (The Rasterman) schrieb: On Fri, 25 Apr 2008 20:26:37 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: it should work now in cvs :) Yup, it works for me, too. Thanks :) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-05-20 07:10:27 -0700
Build log for Enlightenment DR 0.17 on 2008-05-20 07:10:27 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log mixer http://download.enlightenment.org/tests/logs/mixer.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
Diego wrote: We decided to improve the line implementation to speed up the use of evas-lines in python (our case). Yes, we could just use polygons, but we are trying to reduce processor usage at this point. Its faster to draw lines (with lines implementation) directly, specially dealing with vertical/horizontal/45 deg. lines. Calculating where points of polygons must be drawn relative to width of line in python-side is a lost of processing too. Being faster, simpler and without breaking any compatibility, I dont know why Lines should not to have width support. Specially thinking about how simpler it makes to work with Lines. Yes, the code may be optimized, but its working fine and fast here. It may be simpler to have your desired wide lines, but it's not really any faster than using current polygons, nor is it really accurate. But the real issue is simply that this is a terrible way to introduce such abilities in evas - ie. the api (and internals). As I mentioned in an earlier email, one should present this in a more general form so that further stroke/fill aspects can be exposed for not only lines but also rectangles, polygons, and maybe other objects at a later point. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Clipped Smart Object draft
Anyone else looked at this? May I add the clipped smart object (no layout stuff!) to evas? I can add some docs and even change basic smart object to refer to this one for simple implementations. For those who are irc challenged, maybe you could give a short overview of what it is this is supposed to help address, why it should be 'added' to evas, etc. :) It's just a way to help implementation of smart objects. Most common use smart objectcase: create an internal clipper, clip every child to it, move will move children relatively to parent, clip/clip_unset/color/show/hide will all go to the internal clipper. Resize is undefined. What this code provide is this set of default method implementation and an easy to extend base class, just do like in the examples and provide your own methods (be it constructor or resize or show... you name it), which can call the parent. I exposed all the base methods to make it easier to use, one can override show() to do fancy stuff and still call the original to do real work, this could be done differently, having users to copy (ie: parent_class) Smart_Class after evas_object_smart_clipped_smart_set() Why should it be added to Evas: because it's very simple, it's useful and can serve as base for other things. It's definitely useful to have such a ready-made simplifying smart-class construction mechanism that could be 'overriden' - and if you could couple that with some kind of object system for smart data it might even be close to some aspects that the gui toolkits already have. ;) But I'm not sure what you're proposing about doing with it in evas itself..? Do you want to add a new 'clipped smart' object type, or do you want to re-do the current smart stuff so that they have default internal implementations for these smart functions but if the functions are user-specified, then those are used rather than the built-in default ones.. or something of that sort, or what? Actually the idea of such component was born while I was teaching INdT guys and after documenting that you should always do the same stuff for most of methods I opted to add such default implementation and errors went down by a huge factor... actually nowadays it's hard to find a good case to use plain smart object itself. Al, one of things that I failed to figure in the past why show, hide, color_set, clip_set and color_set are ALL marked as DELETE ME. I don't remember for sure, but I think it was rephorm that did say that the common use case is like that and maybe these methods would be replaced with this default implementation only. So it's a good thing in that direction. I've been one who's pointed out issues with these in the past as well, but the truth is that evas is not quite done with exploring those things in full and it may well be that one could want to have other implementations of such methods, or at least 'override' whatever the default ones were.. so it may not be wise to remove them altogether, no matter what jose, rephorm, raster, others may have said in the past :) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Clipped Smart Object draft
On Tue, May 20, 2008 at 3:37 PM, Jose Gonzalez [EMAIL PROTECTED] wrote: Anyone else looked at this? May I add the clipped smart object (no layout stuff!) to evas? I can add some docs and even change basic smart object to refer to this one for simple implementations. For those who are irc challenged, maybe you could give a short overview of what it is this is supposed to help address, why it should be 'added' to evas, etc. :) It's just a way to help implementation of smart objects. Most common use smart objectcase: create an internal clipper, clip every child to it, move will move children relatively to parent, clip/clip_unset/color/show/hide will all go to the internal clipper. Resize is undefined. What this code provide is this set of default method implementation and an easy to extend base class, just do like in the examples and provide your own methods (be it constructor or resize or show... you name it), which can call the parent. I exposed all the base methods to make it easier to use, one can override show() to do fancy stuff and still call the original to do real work, this could be done differently, having users to copy (ie: parent_class) Smart_Class after evas_object_smart_clipped_smart_set() Why should it be added to Evas: because it's very simple, it's useful and can serve as base for other things. It's definitely useful to have such a ready-made simplifying smart-class construction mechanism that could be 'overriden' - and if you could couple that with some kind of object system for smart data it might even be close to some aspects that the gui toolkits already have. ;) But I'm not sure what you're proposing about doing with it in evas itself..? Do you want to add a new 'clipped smart' object type, or do you want to re-do the current smart stuff so that they have default internal implementations for these smart functions but if the functions are user-specified, then those are used rather than the built-in default ones.. or something of that sort, or what? just check ehelpers/evas_object_smart_clipped.[ch], they should go to evas/src/lib/canvas (and .h to Evas.h) no radical change, it's just an extensible way on top of what we have now, that I really feel is enough for our case: you can _VERY_ easily integrate that with other object systems. I did that for Python-EFL. Actually the idea of such component was born while I was teaching INdT guys and after documenting that you should always do the same stuff for most of methods I opted to add such default implementation and errors went down by a huge factor... actually nowadays it's hard to find a good case to use plain smart object itself. Al, one of things that I failed to figure in the past why show, hide, color_set, clip_set and color_set are ALL marked as DELETE ME. I don't remember for sure, but I think it was rephorm that did say that the common use case is like that and maybe these methods would be replaced with this default implementation only. So it's a good thing in that direction. I've been one who's pointed out issues with these in the past as well, but the truth is that evas is not quite done with exploring those things in full and it may well be that one could want to have other implementations of such methods, or at least 'override' whatever the default ones were.. so it may not be wise to remove them altogether, no matter what jose, rephorm, raster, others may have said in the past :) i'm fine with leaving them there, but if people can just avoid using it, we can check if there is any use case left in future and if not, maybe drop it. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas barbieri
to make clear: it COULD be -0, on intel at least it's -1 and thus
evaluates to TRUE, that's why it was unnoticed.
On Tue, May 20, 2008 at 5:56 PM, Enlightenment CVS
[EMAIL PROTECTED] wrote:
Enlightenment CVS committal
Author : barbieri
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/lib/include
Modified Files:
evas_common.h
Log Message:
Remove bugs with bitfield usage, make boolean usage clear.
This patch fixes the problem with bitfield of signed types (ie: char),
where the bit would be used for the signal, so 1 is considered -0 and
thus 0.
Move all the single bit fields to Evas_Bool, making it clear and also
avoiding these problems since Evas_Bool is unsigned char.
===
RCS file: /cvs/e/e17/libs/evas/src/lib/include/evas_common.h,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -3 -r1.97 -r1.98
--- evas_common.h 19 May 2008 03:13:16 - 1.97
+++ evas_common.h 20 May 2008 20:56:39 - 1.98
@@ -283,12 +283,12 @@
struct
{
-unsigned int loaded : 1;
-unsigned int dirty : 1;
-unsigned int activ : 1;
-unsigned int need_data : 1;
-unsigned int lru_nodata : 1;
-unsigned int cached : 1;
+Evas_Boolloaded : 1;
+Evas_Booldirty : 1;
+Evas_Boolactiv : 1;
+Evas_Boolneed_data : 1;
+Evas_Boollru_nodata : 1;
+Evas_Boolcached : 1;
} flags;
intreferences;
@@ -320,11 +320,11 @@
struct
{
- unsigned intcached : 1;
- unsigned intactiv : 1;
- unsigned intdirty : 1;
- unsigned intloaded : 1;
- unsigned intneed_parent : 1;
+ Evas_Bool cached : 1;
+ Evas_Bool activ : 1;
+ Evas_Bool dirty : 1;
+ Evas_Bool loaded : 1;
+ Evas_Bool need_parent : 1;
} flags;
int references;
@@ -347,7 +347,7 @@
struct _RGBA_Draw_Context
{
struct {
- char use : 1;
+ Evas_Bool use : 1;
DATA32 col;
} mul;
struct {
@@ -355,7 +355,7 @@
} col;
struct RGBA_Draw_Context_clip {
intx, y, w, h;
- char use : 1;
+ Evas_Bool use : 1;
} clip;
Cutout_Rects cutout;
struct {
@@ -373,7 +373,7 @@
int y, h;
} sli;
intrender_op;
- unsigned char anti_alias : 1;
+ Evas_Bool anti_alias : 1;
};
struct _RGBA_Pipe_Op
@@ -448,15 +448,15 @@
/* Colorspace stuff. */
struct {
void *data;
- unsigned int no_free : 1;
- unsigned int dirty : 1;
+ Evas_Bool no_free : 1;
+ Evas_Bool dirty : 1;
} cs;
/* RGBA stuff */
struct
{
DATA32*data;
- unsigned int no_free : 1;
+ Evas_Bool no_free : 1;
} image;
};
@@ -483,7 +483,7 @@
float angle;
intdirection;
float offset;
- unsigned char has_alpha : 1;
+ Evas_Bool has_alpha : 1;
} map;
struct {
@@ -515,8 +515,8 @@
int references;
- unsigned char imported_data : 1;
- unsigned char has_alpha : 1;
+ Evas_Bool imported_data : 1;
+ Evas_Bool has_alpha : 1;
};
struct _RGBA_Gradient_Type
@@ -698,12 +698,12 @@
struct _Tilebuf_Tile
{
- unsigned char redraw : 1;
+ Evas_Bool redraw : 1;
/* FIXME: need these flags later - but not now */
/*
- int done : 1;
- int edge : 1;
- int from : 1;
+ Evas_Bool done : 1;
+ Evas_Bool edge : 1;
+ Evas_Bool from : 1;
struct {
int dx, dy;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-cvs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas barbieri
Gustavo Sverzut Barbieri wrote: to make clear: it COULD be -0, on intel at least it's -1 and thus evaluates to TRUE, that's why it was unnoticed. On Tue, May 20, 2008 at 5:56 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/evas Dir : e17/libs/evas/src/lib/include Modified Files: evas_common.h Log Message: Remove bugs with bitfield usage, make boolean usage clear. This patch fixes the problem with bitfield of signed types (ie: char), where the bit would be used for the signal, so 1 is considered -0 and thus 0. Move all the single bit fields to Evas_Bool, making it clear and also avoiding these problems since Evas_Bool is unsigned char. Compilers may complain about signed one bit bitfields, but it is severely broken if a signed one bit bitfield set to 1 evaluates to 0. I would have thought that a signed one bit bitfield set to 1 normally evaluates to -1 which is != TRUE, assuming TRUE is 1. Furthermore, you should not assume anything about the signedness of char. It depends on compiler configuration. /Kim - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas barbieri
On Tue, May 20, 2008 at 6:46 PM, Kim Woelders [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: to make clear: it COULD be -0, on intel at least it's -1 and thus evaluates to TRUE, that's why it was unnoticed. On Tue, May 20, 2008 at 5:56 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/evas Dir : e17/libs/evas/src/lib/include Modified Files: evas_common.h Log Message: Remove bugs with bitfield usage, make boolean usage clear. This patch fixes the problem with bitfield of signed types (ie: char), where the bit would be used for the signal, so 1 is considered -0 and thus 0. Move all the single bit fields to Evas_Bool, making it clear and also avoiding these problems since Evas_Bool is unsigned char. Compilers may complain about signed one bit bitfields, but it is severely broken if a signed one bit bitfield set to 1 evaluates to 0. i see this fact somewhere. I would have thought that a signed one bit bitfield set to 1 normally evaluates to -1 which is != TRUE, assuming TRUE is 1. exactly, forgot to say that. Furthermore, you should not assume anything about the signedness of char. It depends on compiler configuration. exactly, that's why it's now forced to unsigned. on arm it's unsigned, but on pc it's not. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas barbieri
On Tue, 20 May 2008 18:27:32 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
then u'd have a platform that does NOT do 2's compliment math. not compiler but
cpu... and i'd love to see that exist - NOT. :) everything is 2's compliment
and so a 1 bit signed bitfield when on is -1 which as you say - still is
true. it always will be :)
to make clear: it COULD be -0, on intel at least it's -1 and thus
evaluates to TRUE, that's why it was unnoticed.
On Tue, May 20, 2008 at 5:56 PM, Enlightenment CVS
[EMAIL PROTECTED] wrote:
Enlightenment CVS committal
Author : barbieri
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/lib/include
Modified Files:
evas_common.h
Log Message:
Remove bugs with bitfield usage, make boolean usage clear.
This patch fixes the problem with bitfield of signed types (ie: char),
where the bit would be used for the signal, so 1 is considered -0 and
thus 0.
Move all the single bit fields to Evas_Bool, making it clear and also
avoiding these problems since Evas_Bool is unsigned char.
===
RCS file: /cvs/e/e17/libs/evas/src/lib/include/evas_common.h,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -3 -r1.97 -r1.98
--- evas_common.h 19 May 2008 03:13:16 - 1.97
+++ evas_common.h 20 May 2008 20:56:39 - 1.98
@@ -283,12 +283,12 @@
struct
{
-unsigned int loaded : 1;
-unsigned int dirty : 1;
-unsigned int activ : 1;
-unsigned int need_data : 1;
-unsigned int lru_nodata : 1;
-unsigned int cached : 1;
+Evas_Boolloaded : 1;
+Evas_Booldirty : 1;
+Evas_Boolactiv : 1;
+Evas_Boolneed_data : 1;
+Evas_Boollru_nodata : 1;
+Evas_Boolcached : 1;
} flags;
intreferences;
@@ -320,11 +320,11 @@
struct
{
- unsigned intcached : 1;
- unsigned intactiv : 1;
- unsigned intdirty : 1;
- unsigned intloaded : 1;
- unsigned intneed_parent : 1;
+ Evas_Bool cached : 1;
+ Evas_Bool activ : 1;
+ Evas_Bool dirty : 1;
+ Evas_Bool loaded : 1;
+ Evas_Bool need_parent : 1;
} flags;
int references;
@@ -347,7 +347,7 @@
struct _RGBA_Draw_Context
{
struct {
- char use : 1;
+ Evas_Bool use : 1;
DATA32 col;
} mul;
struct {
@@ -355,7 +355,7 @@
} col;
struct RGBA_Draw_Context_clip {
intx, y, w, h;
- char use : 1;
+ Evas_Bool use : 1;
} clip;
Cutout_Rects cutout;
struct {
@@ -373,7 +373,7 @@
int y, h;
} sli;
intrender_op;
- unsigned char anti_alias : 1;
+ Evas_Bool anti_alias : 1;
};
struct _RGBA_Pipe_Op
@@ -448,15 +448,15 @@
/* Colorspace stuff. */
struct {
void *data;
- unsigned int no_free : 1;
- unsigned int dirty : 1;
+ Evas_Bool no_free : 1;
+ Evas_Bool dirty : 1;
} cs;
/* RGBA stuff */
struct
{
DATA32*data;
- unsigned int no_free : 1;
+ Evas_Bool no_free : 1;
} image;
};
@@ -483,7 +483,7 @@
float angle;
intdirection;
float offset;
- unsigned char has_alpha : 1;
+ Evas_Bool has_alpha : 1;
} map;
struct {
@@ -515,8 +515,8 @@
int references;
- unsigned char imported_data : 1;
- unsigned char has_alpha : 1;
+ Evas_Bool imported_data : 1;
+ Evas_Bool has_alpha : 1;
};
struct _RGBA_Gradient_Type
@@ -698,12 +698,12 @@
struct _Tilebuf_Tile
{
- unsigned char redraw : 1;
+ Evas_Bool redraw : 1;
/* FIXME: need these flags later - but not now */
/*
- int done : 1;
- int edge : 1;
- int from : 1;
+ Evas_Bool done : 1;
+ Evas_Bool edge : 1;
+ Evas_Bool from : 1;
struct {
int dx, dy;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-cvs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
Re: [E-devel] E CVS: libs/evas barbieri
On Tue, May 20, 2008 at 8:18 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 20 May 2008 18:27:32 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: then u'd have a platform that does NOT do 2's compliment math. not compiler but cpu... and i'd love to see that exist - NOT. :) everything is 2's compliment and so a 1 bit signed bitfield when on is -1 which as you say yes, this makes sense. - still is true. it always will be :) but as kwo told, -1 != 1, so depends on how you check for true :-/ usually boolean operations will work, but direct comparison will not but yes, i have not seen any == 1 or != 1 in e, so it's bit pointless. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Clipped Smart Object draft
Gustavo wrote: It's definitely useful to have such a ready-made simplifying smart-class construction mechanism that could be 'overriden' - and if you could couple that with some kind of object system for smart data it might even be close to some aspects that the gui toolkits already have. ;) But I'm not sure what you're proposing about doing with it in evas itself..? Do you want to add a new 'clipped smart' object type, or do you want to re-do the current smart stuff so that they have default internal implementations for these smart functions but if the functions are user-specified, then those are used rather than the built-in default ones.. or something of that sort, or what? just check ehelpers/evas_object_smart_clipped.[ch], they should go to evas/src/lib/canvas (and .h to Evas.h) no radical change, it's just an extensible way on top of what we have now, that I really feel is enough for our case: you can _VERY_ easily integrate that with other object systems. I did that for Python-EFL. No radical changes? Well that certainly puts a damper on things Gustavo.. where's the fun in that? :) Ok, I took a look at your ehelpers/evas_object_smart_clipped.[ch] and that's definitely not radical. On a more serious note: If you're not going to really extend evas per-se, just add some convenience constructs for dealing with 'common' kinds of smart objects, then why put this into evas? Why not add it to the esmart lib instead, that's a lib that's used for exactly these kinds of things (it has many useful kinds of smart classes for various things - more should be added). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Embryo documentation
Greetings all. As some of you might have noticed on IRC (and alot of you have helped me) that I am making some Embryo examples of some common and interesting functions for use in various edje themes. Im running into alot of trouble since there is infact, NO documentation on embryo. Sure there is the PAWN and SMALL manuals, but both are quite different from Embryo. eg, the way values are retrieved. Theres also a lack of explanation of the different calls in edje.inc. It is nice to see what the functions need in order to operate, but some things are difficult for a non-coder to understand. eg. x (Personally I sat in confusion looking at that x till mekius guessed it sets the defined variable in that spot.) I noticed the PAWN manual is in a Creative Commons license aswell so that could be a good place to start, and simply edit it. Also, It might be nice to have a few more 'real-world' examples of embryo on the wiki. I started some here... http://wiki.enlightenment.org/index.php/Embryo/Examples And of course the EFL cookbook has a really short section on it, with a nice Toggle example. Id appreciate it if someone could go through my examples and fix/reword anything I have explained wrong. Thoughts? I do understand it takes alot of time to write good docs, but Id be happy to help if I can in writing some examples and such. Toma - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
