[E-devel] checking a part's type?
Hey, I want to check if a given part's type is SWALLOW before using it to
swallow an object.
I couldn't find a way to do it without using Edje_Edit.h. Sice this is for the
Edje book I wouldn't want to encourage Edje_Edit for regular application
development. Or is promoting the usage of Edje_Edit in applications a good
idea?
My approach was to add a new function to Edje that return the part type as an
unsigned char (like Edje_Edit does) and to move the macros EDJE_PART_TYPE_*
from edje_private.h to Edje.h .
I attached a patch showing the changes.
Thanks and good bye.
Index: src/lib/Edje.h
===
RCS file: /cvs/e/e17/libs/edje/src/lib/Edje.h,v
retrieving revision 1.52
diff -u -r1.52 Edje.h
--- src/lib/Edje.h 26 Aug 2007 12:54:51 - 1.52
+++ src/lib/Edje.h 16 Apr 2008 13:53:35 -
@@ -24,6 +24,16 @@
# endif
#endif
+#define EDJE_PART_TYPE_NONE 0
+#define EDJE_PART_TYPE_RECTANGLE 1
+#define EDJE_PART_TYPE_TEXT 2
+#define EDJE_PART_TYPE_IMAGE 3
+#define EDJE_PART_TYPE_SWALLOW 4
+#define EDJE_PART_TYPE_TEXTBLOCK 5
+#define EDJE_PART_TYPE_GRADIENT 6
+#define EDJE_PART_TYPE_GROUP 7
+#define EDJE_PART_TYPE_LAST 8
+
/* FIXDOC: Define these? */
enum _Edje_Message_Type
{
@@ -195,7 +205,8 @@
EAPI Evas_Object *edje_object_add (Evas *evas);
/* edje_util.c */
- EAPI const char *edje_object_data_get(Evas_Object *obj, const char *key);
+ EAPI const char*edje_object_data_get(Evas_Object *obj, const char *key);
+ EAPI unsigned char edje_object_part_type_get (Evas_Object *obj, const char *part);
/* edje_load.c */
EAPI int edje_object_file_set(Evas_Object *obj, const char *file, const char *part);
Index: src/lib/edje_private.h
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_private.h,v
retrieving revision 1.147
diff -u -r1.147 edje_private.h
--- src/lib/edje_private.h 1 Apr 2008 21:33:17 - 1.147
+++ src/lib/edje_private.h 16 Apr 2008 13:53:35 -
@@ -186,16 +186,6 @@
#define EDJE_IMAGE_SOURCE_TYPE_EXTERNAL 3
#define EDJE_IMAGE_SOURCE_TYPE_LAST 4
-#define EDJE_PART_TYPE_NONE 0
-#define EDJE_PART_TYPE_RECTANGLE 1
-#define EDJE_PART_TYPE_TEXT 2
-#define EDJE_PART_TYPE_IMAGE 3
-#define EDJE_PART_TYPE_SWALLOW 4
-#define EDJE_PART_TYPE_TEXTBLOCK 5
-#define EDJE_PART_TYPE_GRADIENT 6
-#define EDJE_PART_TYPE_GROUP 7
-#define EDJE_PART_TYPE_LAST 8
-
#define EDJE_TEXT_EFFECT_NONE0
#define EDJE_TEXT_EFFECT_PLAIN 1
#define EDJE_TEXT_EFFECT_OUTLINE 2
Index: src/lib/edje_util.c
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_util.c,v
retrieving revision 1.106
diff -u -r1.106 edje_util.c
--- src/lib/edje_util.c 31 Mar 2008 21:38:51 - 1.106
+++ src/lib/edje_util.c 16 Apr 2008 13:53:36 -
@@ -697,6 +697,29 @@
return 1;
}
+/** Gets the type of a given part
+ * @param obj A valid Evas_Object handle
+ * @param part The part name to check
+ * @return An unsigned char representing the type of the part, this value can
+ * be checked agains the following macros, EDJE_PART_TYPE_NONE,
+ * EDJE_PART_TYPE_RECTANGLE, EDJE_PART_TYPE_TEXT,EDJE_PART_TYPE_IMAGE,
+ * EDJE_PART_TYPE_SWALLOW, EDJE_PART_TYPE_TEXTBLOCK,EDJE_PART_TYPE_GRADIENT or
+ * EDJE_PART_TYPE_GROUP. The function returns the value of the macro
+ * EDJE_PART_TYPE_LAST on failure.
+ */
+EAPI unsigned char
+edje_object_part_type_get(Evas_Object *obj, const char *part)
+{
+ Edje *ed;
+ Edje_Real_Part *rp;
+
+ ed = _edje_fetch(obj);
+ if ((!ed) || (!part)) return EDJE_PART_TYPE_LAST;
+ rp = _edje_real_part_recursive_get(ed, (char *)part);
+ if (!rp) return EDJE_PART_TYPE_LAST;
+ return rp-part-type;
+}
+
/**
* Gets the Evas_Object corresponding to a given part.
* You should never modify the state of the returned object
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
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-04-16 07:09:19 -0700
Build log for Enlightenment DR 0.17 on 2008-04-16 07:09:19 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log engage http://download.enlightenment.org/tests/logs/engage.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, 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, 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, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, 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 the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 patch
Dariusz Knociński wrote: Hi All, I wrote new version of some procedures in Imlib2 library and attached patches for that mail. In file color-helpres procedures : void __imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v ); void __imlib_hsv_to_rgb( float h, float s, float v, int *r, int *g, int *b ); I have changed the range of parameters hue from 0-100 to 0-360, and saturation and value from 0-100 to 0-1. This is correct to last version of documentation on the web page. In file grad.c procedures : void __imlib_MapRange( ImlibRange * rg, int len ) void __imlib_MapHsvaRange( ImlibRange * rg, int len ) I have changed internal variable inc from: inc = ((ll - 1) 16) / (len); to: inc = ((ll - 1) 16) / (len-1); This patch repair bug for small values of parameter len, for example from 2 to 16. And I apply two small screenshots of application imlib2_colorspace befor and after patch. The patch applies/compiles cleanly and seems to fix the problem in imlib2_colorspace - haven't checked beyond that. I'll commit this if there are no objections and noone beats me to it :) /Kim - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Carsten wrote: Anyway... Since you're still thinking about all this, and since this has already been discussed at bossa, I'll drop the issue. there is always room for input and discussion. until someone actually knuckles down and starts doing this, discussion is good as it means we will explore all the use cases, corner cases, issues etc. you did bring up the good point of Ok, I'll give you some further 'input' on all this. :) Part of the problem here is that something as large and important to evas as this needs further public discussion... and mentioning decisions/discussions by an unspecified 'we', or possible feature requests by 'clients', is not a good way to get this done. I also know that adding any of this to evas is going to mean a fairly large re-working of the image internals (among other things), and that although a general 'filters' mechanism is a very powerful thing, there are many, many aspects here that need to be considered carefully. Now, despite the discussions that were done at bossa, it's clear to me that not everyone there seems to have the same idea as to just what was decided - if anything. First, it seemed that 'filters' were to be a new type of evas object which were to be used via the current 'clipping' api - at least that's what I thought was being proposed, and you, raster, did as well. Gustavo then mentioned that no, it was to be thru a similar mechanism, but not actually as clip objects. Finally, raster then further mentions something which seems somewhat like some other vague stuff I'd mentioned as well, but nothing seems particularly clear either. No mention is made of any real api for defining these 'filters' or how to deal with a variety of things like image-fills/borders, or with smart objects (apart from a vague remark about adjoining parent filters to members), or how to best implement any of this with the various engines (apart from some vague remarks about gl shaders and a gallium3d lib), or how to represent these things for use with things like edje, etc... In short, it's all been mostly a lot of vague nothing. So, does anyone have anything more concrete to propose here? Perhaps some further specifics discussed at bossa? If not, then I will suggest some. jose. PS. Some here would like to have ultimately flexible 'filters' defined via some cpugpu supported shading language (a kind of gfx scripting mechanism), but I seriously doubt that anyone here is going to spend the time and effort required to design and implement such a thing for evas. Thus, if evas' filters/transforms system is designed exclusively around such an approach, it would mean a hard dependence on eith gl-shaders or gallium3d or some such lib that would offer this functionality. I believe this should be an option.. ie. an optionally compiled, loadable ability, not a built-in requirement for evas just to allow for geometric transforms, especially since these are so easily obtained with software and readily supported in xrender and gl. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] R: I made a plain Edje viewer
I got this error on make: [EMAIL PROTECTED]:~/e/plain_edje_viewer$ make edje_cc -fd data/themes/fonts -id data/themes/default_images data/themes/default.edc build/default.edj mkdir -p ./build gcc -W -Wall -Werror -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -O -Wuninitialized \ -o ./build/plain_edje_viewer src/main.c `pkg-config --libs \ --cflags ecore ecore-evas evas edje ecore-config` In file included from src/main.c:1: src/framework.c:392:2: error: no newline at end of file In file included from src/main.c:2: src/viewport.c:240:2: error: no newline at end of file In file included from src/main.c:3: src/minimap.c:224:2: error: no newline at end of file src/main.c:102:2: error: no newline at end of file make: *** [app] Error 1 you shoud remove -Werror from the Makefile then it work. - andres [EMAIL PROTECTED] ha scritto: Hello, I created a plain edje viewer for this Edje book I'm writtng. If anyone has time to waste and feel like taking a look the url is http://andresblanc.googlepages.com/plain_edje_viewer.tar.gz thank you and good bye - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] R: checking a part's type?
- andres [EMAIL PROTECTED] ha scritto: Hey, I want to check if a given part's type is SWALLOW before using it to swallow an object. Why you need to do this check? edje_object_part_swallow do it for you ;) I couldn't find a way to do it without using Edje_Edit.h. Sice this is for the Edje book I wouldn't want to encourage Edje_Edit for regular application development. Or is promoting the usage of Edje_Edit in applications a good idea? no, no, no, it's not a good idea. My approach was to add a new function to Edje that return the part type as an unsigned char (like Edje_Edit does) and to move the macros EDJE_PART_TYPE_* from edje_private.h to Edje.h . This is ok for me I attached a patch showing the changes. Thanks and good bye. The patch is good and simple ... if we really need it :) Bye Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] R: checking a part's type?
El Wednesday 16 April 2008 18:05:40 Dave Andreoli escribió: - andres [EMAIL PROTECTED] ha scritto: Hey, I want to check if a given part's type is SWALLOW before using it to swallow an object. Why you need to do this check? edje_object_part_swallow do it for you ;) Edje's swallow function doesn't check that the swallower is actually a SWALLOW part, AFIK it will fail silently. So other than using edje_object_part_swallow_get and checking the object returned is the same you tried to swallow there is no way to know if the swallowing was successful or why did it fail. We could put checks like this in edje_object_part_swallow. But I can't help to think was programmed to work this way for a reason I ignore. In a completely unrelated note I spiced up the plain edje viewer (and removed the loony CFLAGS this time). Now you can set the size of the viewed object to the size of the window with something that looks like an arrow next to the minimap. http://andresblanc.googlepages.com/plain_edje_viewer.tar.gz bye I couldn't find a way to do it without using Edje_Edit.h. Sice this is for the Edje book I wouldn't want to encourage Edje_Edit for regular application development. Or is promoting the usage of Edje_Edit in applications a good idea? no, no, no, it's not a good idea. My approach was to add a new function to Edje that return the part type as an unsigned char (like Edje_Edit does) and to move the macros EDJE_PART_TYPE_* from edje_private.h to Edje.h . This is ok for me I attached a patch showing the changes. Thanks and good bye. The patch is good and simple ... if we really need it :) Bye Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja vaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 patch
Dariusz Knociński wrote:
Patch:
diff -u -p -r imlib2-1.4.1.000.old/src/lib/color_helpers.c
imlib2-1.4.1.000.new/src/lib/color_helpers.c
--- imlib2-1.4.1.000.old/src/lib/color_helpers.c 2007-05-21
00:58:01.0 +0200
+++ imlib2-1.4.1.000.new/src/lib/color_helpers.c 2008-04-15
09:34:36.0 +0200
@@ -5,117 +5,89 @@
*/
void
-__imlib_rgb_to_hsv(int r, int g, int b, float *h, float *s, float *v)
+__imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v )
{
- int min, max;
- int delta;
+ register float min, max, delta;
- max = (r + g + abs(r - g)) / 2;
- max = (max + b + abs(max - b)) / 2;
- min = (r + g - abs(r - g)) / 2;
- min = (min + b - abs(min - b)) / 2;
+min = ((( r g ) ? r : g) b ) ? (( r g ) ? r : g) : b;
+max = ((( r g ) ? r : g) b ) ? (( r g ) ? r : g) : b;
- delta = max - min;
- *v = (float)(100 * max) / 255.0;
-
- if (max != 0)
- *s = (float)(100 * delta) / (float)max;
- else
- {
-*s = 0.0;
+*v = max / 255.0;
+ delta = ( max - min );
+if( delta == 0 )
+{
*h = 0.0;
-*v = 0.0;
- }
- if (r == max)
- {
-*h = (float)(100 * (g - b)) / (float)(6.0 * delta);
- }
- else
- {
-if (g == max)
- {
- *h = (float)(100 * (2 * delta + b - r)) / (float)(6.0 * delta);
- }
-else
- {
- *h = (float)(100 * (4 * delta + r - g)) / (float)(6.0 * delta);
- }
- }
- if (*h 0.0)
- *h += 100.0;
- if (*h 100.0)
- *h -= 100.0;
+*s = 0.0;
+return;
+}
+*s = delta / max;
+ if( r == max )
+ *h = ( g - b ) / delta;
+ else if( g == max )
+ *h = 2.0 + ( b - r ) / delta;
+ else
+ *h = 4.0 + ( r - g ) / delta;
+ *h *= 60.0;
+ if( *h 0 )
+ *h += 360.0;
}
void
__imlib_hsv_to_rgb(float h, float s, float v, int *r, int *g, int *b)
{
- float hh, f;
- float p, q, t;
- int i;
+register float f, vf;
+register int i, p, q, t, vv;
- if (s == 0.0)
- {
-*r = round((v * 255.0) / 100.0);
-*g = round((v * 255.0) / 100.0);
-*b = round((v * 255.0) / 100.0);
+vf = 255.0 * v;
+vv = (int)round( vf );
+if( s == 0.0 )
+{
+*r = *g = *b = vv;
return;
- }
-
- hh = (h * 6.0) / 100.0;
- i = floor(hh);
- f = hh - (float)i;
-
- p = v * (1.0 - s / 100.0) / 100.0;
- q = v * (1.0 - (s * f) / 100.0) / 100.0;
- t = v * (1.0 - s * (1.0 - f) / 100.0) / 100.0;
+}
- switch (i)
- {
- case 0:
-{
- *r = round(v * 255.0 / 100.0);
- *g = round(t * 255.0);
- *b = round(p * 255.0);
- break;
-}
- case 1:
-{
- *r = round(q * 255.0);
- *g = round(v * 255.0 / 100.0);
- *b = round(p * 255.0);
- break;
-}
- case 2:
-{
- *r = round(p * 255.0);
- *g = round(v * 255.0 / 100.0);
- *b = round(t * 255.0);
- break;
-}
- case 3:
-{
- *r = round(p * 255.0);
- *g = round(q * 255.0);
- *b = round(v * 255.0 / 100.0);
- break;
-}
- case 4:
-{
- *r = round(t * 255.0);
- *g = round(p * 255.0);
- *b = round(v * 255.0 / 100.0);
- break;
-}
- case 5:
-{
- *r = round(v * 255.0 / 100.0);
- *g = round(p * 255.0);
- *b = round(q * 255.0);
- break;
-}
- }
+h /= 60.0;
+i = floor(h);
+f = h - (float)i;
+p = (int)round( vf * (1.0 - s ));
+q = (int)round( vf * (1.0 - (s * f)));
+t = (int)round( vf * (1.0 - s * (1.0 - f)));
+
+switch( i % 6 )
+{
+case 0:
+*r = vv;
+*g = t;
+*b = p;
+break;
+case 1:
+*r = q;
+*g = vv;
+*b = p;
+break;
+case 2:
+*r = p;
+*g = vv;
+*b = t;
+break;
+case 3:
+*r = p;
+*g = q;
+*b = vv;
+break;
+case 4:
+*r = t;
+*g = p;
+*b = vv;
+break;
+case 5:
+default:
+*r = vv;
+*g = p;
+*b = q;
+break;
+}
}
void
diff -u -p -r imlib2-1.4.1.000.old/src/lib/grad.c
imlib2-1.4.1.000.new/src/lib/grad.c
--- imlib2-1.4.1.000.old/src/lib/grad.c 2007-05-21 00:58:01.0
+0200
+++ imlib2-1.4.1.000.new/src/lib/grad.c 2008-04-15 09:29:32.0
+0200
@@ -112,7 +112,7 @@ __imlib_MapRange(ImlibRange * rg, int le
pmap[i++] = (a 24) | (r
Re: [E-devel] Evas transforms/filters/etc.
Sorry for not much time to reply to this in depth, probably raster will do it, by my point goes for the last statement: On Wed, Apr 16, 2008 at 3:45 PM, Jose Gonzalez [EMAIL PROTECTED] wrote: PS. Some here would like to have ultimately flexible 'filters' defined via some cpugpu supported shading language (a kind of gfx scripting mechanism), but I seriously doubt that anyone here is going to spend the time and effort required to design and implement such a thing for evas. Thus, if evas' filters/transforms system is designed exclusively around such an approach, it would mean a hard dependence on eith gl-shaders or gallium3d or some such lib that would offer this functionality. I believe this should be an option.. ie. an optionally compiled, loadable ability, not a built-in requirement for evas just to allow for geometric transforms, especially since these are so easily obtained with software and readily supported in xrender and gl. The point of it being generic, at least for ME (not we, don't care about others agreeing or not) is to enable you to write such filters and plug them. You write then, you just have to implement the API and you're done. If you want to set a matrix, you specify it and you set it. If you want to be dependent on GL, do it on your code, use it from your application. Of course Evas should provide some good one, generic, by default. But I'll not work on this now (maybe in future). But so far what I want is to (_very rough_ draft of the possible API): - negotiate(to_filter_objects, parent filter, child filter) - bounding_boxes_get(to_filter_objects, ...) // maybe return a polygon, dunno - allocate(bbs) - dst_surfs - apply(to_filter_objects, dst_surfs) On the first call we could try to be bit smarter and collapse filters we know about. Default negotiation is to allocate a temporary buffer to be used in apply(). The second call can be used to get the size of the required buffers to allocate, Evas will calculate the biggest BB if filters are negotiated do use the same buffer. This can be also used to mark evas region as dirty... maybe we can return a polygon here and support dirty areas as polygon in Evas... who knows. For now I'd just return a list/vector of rectangles to use, in the case we want disconnected regions (ie: exploding effects). The third major call is meant to allocate temporary buffers, which might be OpenGL framebuffers, simple malloc() regions The last major call would be apply() that would take care to draw things to its temporary buffer. The input, to_filter_objects, is the objects to use if they're not filtered by some non-cooperating filter before, or the result (tmp_buffer) with the result of previous filtering. As you can see it's all about negotiation. At least for me. That's not that complicated and would enable users to do nice effects. Of course we could provide nice filters by default, with great apis, but these can come later. We can do some tests with this and see if it will work as expected. As for API for these provided filters, we could use: Evas_Filter *f1 = evas_filter_rotation_new(evas, degree); Evas_Filter *f2 = evas_filter_blur_new(evas, EVAS_FILTER_BLUR_GAUSIAN, 2.5); Evas_Object *o = evas_object_image_add(evas); //... evas_object_filter_set(o, f1); evas_filter_filter_set(f1, f2); or you can make these special objects, like we have Smart Objects being Evas_Object... keep the API similar. Does it help a bit? Sorry not having much time to explain my ideas in a better way, or sounding too rude or writing some test code. -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ewl build error for fb
Hey, fixed in cvs (with a small modification). Thanks Vincent On Thu, 17 Apr 2008, Manfred Gruber wrote: hi ! here is a small patch for compiling ewl for fb, evas-fb is the package to search for, not evas-framebuffer Index: ewl/configure.in === --- ewl/configure.in +++ ewl/configure.in @@ -195,7 +195,7 @@ PKG_CHECK_MODULES(ECORE_FB, [have_ecore_framebuffer=yes], [have_ecore_framebuffer=no]) -EWL_CHECK_ENGINE([framebuffer], [framebuffer], [0.9.9], [$have_ecore_framebuffer]) +EWL_CHECK_ENGINE([fb], [fb], [0.9.9], [$have_ecore_framebuffer]) dnl Buffer engine Index: ewl/src/engines/evas_fb/Makefile.am === --- ewl/src/engines/evas_fb/Makefile.am +++ ewl/src/engines/evas_fb/Makefile.am @@ -10,7 +10,7 @@ AM_CPPFLAGS = \ pkgdir = $(libdir)/ewl/engines -if EWL_ENABLE_EVAS_FRAMEBUFFER +if EWL_ENABLE_EVAS_FB pkg_LTLIBRARIES = evas_fb.la -- mfg Manfred Gruber - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. Message délivré par le serveur de messagerie de l'Université d'Evry. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
