Re: [E-devel] Evas transforms/filters/etc.
I wrote: However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. - 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.
On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. I must say that I don't really see the difference between your two proposal. Perhaps if you can propose the set of functions that will be exported by Evas to the external developper, it will be easier to understand and discuss. -- Cedric BAIL - 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] [PATCH] edje: remove unused fnmatch.h include
fnmatch is not used in edje anymore. Attached trivial patch removes the last traces of its existence in edje. Index: INSTALL === RCS file: /var/cvs/e/e17/libs/edje/INSTALL,v retrieving revision 1.2 diff -u -r1.2 INSTALL --- INSTALL 26 Aug 2007 12:54:51 - 1.2 +++ INSTALL 11 Apr 2008 11:32:46 - @@ -12,8 +12,3 @@ make install NOTE: You MUST make install Edje for it to run properly. - -NOTE: for compilation with MinGW, fnmatch.h is probably missing. - That file can be found here: -http://www.koders.com/c/fid2B518462CB1EED3D4E31E271DB83CD1582F6EEBE.aspx - It should be installed in the mingw include directory. Index: src/bin/edje_prefix.c === RCS file: /var/cvs/e/e17/libs/edje/src/bin/edje_prefix.c,v retrieving revision 1.6 diff -u -r1.6 edje_prefix.c --- src/bin/edje_prefix.c 27 Aug 2007 09:32:17 - 1.6 +++ src/bin/edje_prefix.c 11 Apr 2008 11:32:49 - @@ -12,7 +12,6 @@ #include sys/time.h #include sys/param.h #include math.h -#include fnmatch.h #include limits.h #include ctype.h #include time.h - 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-11 07:08:48 -0700
Build log for Enlightenment DR 0.17 on 2008-04-11 07:08:48 -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] [PATCH] evas-framebuffer.pc.in rename
On Mon, 7 Apr 2008, Lars Munch wrote: Hi Unfortunately the addition off expedite_check_engine.m4 in expedite broke the detection of the framebuffer engine in expedite. The course of this is an inconsistent naming of the file evas-framebuffer.pc.in which should be named evas-fb.pc.in to be consistent with the other engine names. can't we just modify what is checked in expedite ? That is configure.in, a Makefile.am and 1 or 2 files. Vincent The attached patch renames this file an changes Configure.in and Makefile.am in ecore and evas accordingly. A quick grep in the cvs repository indicates that expedite is the only project that actually uses evas-framebuffer.pc, so the breakage of applying this patch should be minimal. Regards Lars Munch -- 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
Re: [E-devel] [PATCH] evas-framebuffer.pc.in rename
On Fri, Apr 11, 2008 at 04:27:18PM +0200, Vincent Torri wrote: On Mon, 7 Apr 2008, Lars Munch wrote: Hi Unfortunately the addition off expedite_check_engine.m4 in expedite broke the detection of the framebuffer engine in expedite. The course of this is an inconsistent naming of the file evas-framebuffer.pc.in which should be named evas-fb.pc.in to be consistent with the other engine names. can't we just modify what is checked in expedite ? That is configure.in, a Makefile.am and 1 or 2 files. yes, that's the easy solution, but IMHO consistent naming is better in the long run. Regards Lars Munch - 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] [RFC] Caching the result of evas_render_phase1_object_process
Hi,
Some of you already know, I am working on improving the speed of
evas_render_phase1_object_process. The idea is that the list of
active_object, and object to render will change much between to call
to evas_render.
I started by removing the use of evas_list and use a growing array
of evas_object that is only freed on idle. This does bring only a
small speed improvement. Then I started to cache the result
evas_render_phase1_object_process and keep it alive except on layer
change, show, hide and some color set case. On move and resize I
wanted to just check if the state of stack of call to render_pre is
still valid and call them accordingly. It's almost working. Just the
resize is not. I don't understand why yet, but I can't make it work
the same way as the move. Perhaps someone can help me on understanding
this.
So the code is attached for your fun, but don't commit it or it
will break for sure :-)
--
Cedric BAIL
diff --git a/src/lib/canvas/evas_main.c b/src/lib/canvas/evas_main.c
index 7313a33..573e386 100644
--- a/src/lib/canvas/evas_main.c
+++ b/src/lib/canvas/evas_main.c
@@ -85,6 +85,8 @@ evas_free(Evas *e)
return;
MAGIC_CHECK_END();
+ if (e-walking_list == 0) evas_render_idle_flush(e);
+
if (e-walking_list 0) return;
del = 1;
e-walking_list++;
diff --git a/src/lib/canvas/evas_object_main.c b/src/lib/canvas/evas_object_main.c
index 5fb3edc..9a75ee2 100644
--- a/src/lib/canvas/evas_object_main.c
+++ b/src/lib/canvas/evas_object_main.c
@@ -483,6 +483,7 @@ evas_object_del(Evas_Object *obj)
while (obj-clip.clipees) evas_object_clip_unset(obj-clip.clipees-data);
if (obj-cur.clipper) evas_object_clip_unset(obj);
if (obj-smart.smart) evas_object_smart_del(obj);
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
evas_object_event_callback_call(obj, EVAS_CALLBACK_FREE, NULL);
evas_object_smart_cleanup(obj);
obj-delete_me = 1;
@@ -534,6 +535,7 @@ evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
obj-layer-evas-pointer.x,
obj-layer-evas-pointer.y, 1, 1);
}
+ evas_render_object_recalc(obj);
obj-cur.geometry.x = x;
obj-cur.geometry.y = y;
obj-cur.cache.geometry.validity = 0;
@@ -607,6 +609,9 @@ evas_object_resize(Evas_Object *obj, Evas_Coord w, Evas_Coord h)
obj-layer-evas-pointer.x,
obj-layer-evas-pointer.y, 1, 1);
}
+ /* FIXME: This should really call evas_render_object_recalc */
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
+/*evas_render_object_recalc(obj); */
obj-cur.geometry.w = w;
obj-cur.geometry.h = h;
obj-cur.cache.geometry.validity = 0;
@@ -699,6 +704,7 @@ evas_object_show(Evas_Object *obj)
evas_object_inform_call_show(obj);
return;
}
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
obj-cur.visible = 1;
evas_object_change(obj);
evas_object_clip_dirty(obj);
@@ -746,6 +752,7 @@ evas_object_hide(Evas_Object *obj)
evas_object_inform_call_hide(obj);
return;
}
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
obj-cur.visible = 0;
evas_object_change(obj);
evas_object_clip_dirty(obj);
@@ -859,7 +866,10 @@ evas_object_color_set(Evas_Object *obj, int r, int g, int b, int a)
obj-cur.color.r = r;
obj-cur.color.g = g;
obj-cur.color.b = b;
+ if ((obj-cur.color.a == 0) || (a == 0))
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
if ((obj-cur.color.a == 0) (a == 0)) return;
+ evas_render_object_recalc(obj);
obj-cur.color.a = a;
evas_object_change(obj);
}
diff --git a/src/lib/canvas/evas_render.c b/src/lib/canvas/evas_render.c
index ccc5c52..7589869 100644
--- a/src/lib/canvas/evas_render.c
+++ b/src/lib/canvas/evas_render.c
@@ -4,6 +4,42 @@
static Evas_List *
evas_render_updates_internal(Evas *e, unsigned char make_updates, unsigned char do_draw);
+static inline void
+_evas_object_array_push(Evas_Array *array, Evas_Object *obj)
+{
+ if (!array) return ;
+ if (array-count + 1 array-total)
+ {
+Evas_Object **tmp;
+unsigned int total;
+
+total = array-total + 16;
+tmp = realloc(array-obj, sizeof (Evas_Object*) * total);
+if (!tmp) return ;
+
+array-total = total;
+array-obj = tmp;
+ }
+
+ array-obj[array-count++] = obj;
+}
+
+static void
+_evas_object_array_clean(Evas_Array *array)
+{
+ array-count = 0;
+}
+
+static void
+_evas_object_array_free(Evas_Array *array)
+{
+ array-count = 0;
+ array-total = 0;
+
+ if (array-obj) free(array-obj);
+ array-obj = NULL;
+}
+
/**
* To be documented.
*
@@ -68,24 +104,62 @@ evas_obscured_clear(Evas *e)
}
static void
-_evas_render_phase1_object_process(Evas *e, Evas_Object *obj, Evas_List **active_objects, Evas_List **restack_objects, Evas_List **delete_objects, int restack)
+_evas_render_phase1_direct(Evas *e, Evas_Array *render_objects)
{
- int is_active;
-
+ int i;
+
+ for
Re: [E-devel] Evas transforms/filters/etc.
Cedric wrote: On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez wrote: I wrote: However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. I must say that I don't really see the difference between your two proposal. Perhaps if you can propose the set of functions that will be exported by Evas to the external developper, it will be easier to understand and discuss. The main difference is that of avoiding the iterative 'clipping' mechanism as the single method for doing everything. What you want is something like: A clips B clips C clips D clips E clips F clips G clips H say, where H is eg. an image obj and G a transform obj and F a rect obj and E a blur filter and D a gradient obj and C a . with the result of obtaining a transformed image which is multiplied by blurred rect which is multiplied by gradient which is then composited to the dst. Also, some of these clippers may be clipping other objs. Very succint, very extensive... very likely to be difficult to optimize for simple, commom-use cases, and even more likely to not be used in this kind of arbitrary generality. Also likely to be problematic with smart objs and difficult to use for basic things.. imagine setting a trnasform on an image obj that's already had a rect set as a clip - one'd have to unset the rect clipper, set the transf as the new clipper, and set the rect as the clipper of the transform.. and that's just one example of the kinds of things that come up with this approach. I'm suggesting that one avoid this temptation, leave clipping as is for now (plain rects), and instead add separate api funcs to set a geometric trnasform, to set a mask (image or grad, no masking a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, ... possibly allow for chaining these). If one wants more than this, then there are several ways to obtain things - eg. introduce a 'drawing obj' type which essentially allows for one to iterate these things by allowing one to 'add' other objs to it (much like a group obj), including ones like it, and extend masks to also be of this type. Anything beyond that should probably be the domain of custom objs that can use whatever methods/apis they have access to.. gl, shaders. whatever. But keep the core, built-in stuff simple, efficient, natural and also flexible enough to obtain more complex things if desired. - 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.
On Fri, Apr 11, 2008 at 4:29 PM, Jose Gonzalez [EMAIL PROTECTED] wrote: Cedric wrote: On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez wrote: I wrote: However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. I must say that I don't really see the difference between your two proposal. Perhaps if you can propose the set of functions that will be exported by Evas to the external developper, it will be easier to understand and discuss. The main difference is that of avoiding the iterative 'clipping' mechanism as the single method for doing everything. What you want is something like: A clips B clips C clips D clips E clips F clips G clips H say, where H is eg. an image obj and G a transform obj and F a rect obj and E a blur filter and D a gradient obj and C a . with the result of obtaining a transformed image which is multiplied by blurred rect which is multiplied by gradient which is then composited to the dst. Also, some of these clippers may be clipping other objs. Very succint, very extensive... very likely to be difficult to optimize for simple, commom-use cases, and even more likely to not be used in this kind of arbitrary generality. Also likely to be problematic with smart objs and difficult to use for basic things.. imagine setting a trnasform on an image obj that's already had a rect set as a clip - one'd have to unset the rect clipper, set the transf as the new clipper, and set the rect as the clipper of the transform.. and that's just one example of the kinds of things that come up with this approach. I'm suggesting that one avoid this temptation, leave clipping as is for now (plain rects), and instead add separate api funcs to set a geometric trnasform, to set a mask (image or grad, no masking a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, ... possibly allow for chaining these). Well, you misunderstood me then. Filters would behave like clippers, but not use the clipper mechs... I think I tried to say that in my email. We'd have both clippers and filters as separate lists. Clippers, in far, far, far.. future, will add some of what you want, as clip to a bitmap and get a mask, clip to a gradient and get nice fade-out of clipped items. That's what raster want to provide AFAIK. Filters will just be filtered by filters, so it's like SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 will get these 3 filters. Example, F1 could be blur, while F2 be rotation and F3 be scale. Of course one could implement F1 as a weird filter that uses fragment shaders to provide a fade-out effect, so eliminating the need for that in clipper. If one wants more than this, then there are several ways to obtain things - eg. introduce a 'drawing obj' type which essentially allows for one to iterate these things by allowing one to 'add' other objs to it (much like a group obj), including ones like it, and extend masks to also be of this type. Anything beyond that should probably be the domain of custom objs that can use whatever methods/apis they have access to.. gl, shaders. whatever. But keep the core, built-in stuff simple, efficient, natural and also flexible enough to obtain more complex things if desired. they will remain like this, no existing code should be influenced by these changes. -- 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.
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: The main difference is that of avoiding the iterative 'clipping' mechanism as the single method for doing everything. What you want is something like: A clips B clips C clips D clips E clips F clips G clips H say, where H is eg. an image obj and G a transform obj and F a rect obj and E a blur filter and D a gradient obj and C a . with the result of obtaining a transformed image which is multiplied by blurred rect which is multiplied by gradient which is then composited to the dst. Also, some of these clippers may be clipping other objs. Very succint, very extensive... very likely to be difficult to optimize for simple, commom-use cases, and even more likely to not be used in this kind of arbitrary generality. Also likely to be problematic with smart objs and difficult to use for basic things.. imagine setting a trnasform on an image obj that's already had a rect set as a clip - one'd have to unset the rect clipper, set the transf as the new clipper, and set the rect as the clipper of the transform.. and that's just one example of the kinds of things that come up with this approach. I'm suggesting that one avoid this temptation, leave clipping as is for now (plain rects), and instead add separate api funcs to set a geometric trnasform, to set a mask (image or grad, no masking a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, ... possibly allow for chaining these). Well, you misunderstood me then. Filters would behave like clippers, but not use the clipper mechs... I think I tried to say that in my email. We'd have both clippers and filters as separate lists. Clippers, in far, far, far.. future, will add some of what you want, as clip to a bitmap and get a mask, clip to a gradient and get nice fade-out of clipped items. That's what raster want to provide AFAIK. I don't think clippers should enable that - raster and others may though. I already implemented this once.. and didn't like it. I'd separate masking as its own operation, and leave clipping as is. As far as filters having their own api funcs but incorporating both geometric transforms and various filter effects (blur, whatnot), and chainable.. that may be ok (possibly still somewhat unwarranted for most needs). Filters will just be filtered by filters, so it's like SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 will get these 3 filters. Example, F1 could be blur, while F2 be rotation and F3 be scale. Of course one could implement F1 as a weird filter that uses fragment shaders to provide a fade-out effect, so eliminating the need for that in clipper. That is very easy to obtain via (projective) transforms and masks (image, grads, or general 'drawing objs'), without having to invoke fragment shaders. If one wants more than this, then there are several ways to obtain things - eg. introduce a 'drawing obj' type which essentially allows for one to iterate these things by allowing one to 'add' other objs to it (much like a group obj), including ones like it, and extend masks to also be of this type. Anything beyond that should probably be the domain of custom objs that can use whatever methods/apis they have access to.. gl, shaders. whatever. But keep the core, built-in stuff simple, efficient, natural and also flexible enough to obtain more complex things if desired. they will remain like this, no existing code should be influenced by these changes. What does that have to do with anything we're discussing here? - 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] PATH: Fix Makefile rules ecore-evas submodule
On Thu, 13 Mar 2008 13:29:37 +0100 [EMAIL PROTECTED] babbled: no patch attached? Hello, Since this morning, when i tried to compile ecore with ecore-sdl support (so --enable-ecore-sdl) build failed for libecore-evas with the following message : Unable to resolve -L/usr/lib target depending on libecore-evas.la the problem was : In Makefile.am automake rules , if BUILD_ECORE_SDL is defined ECORE_SDL_LIB var was affected with @SDL_LIBS@ LDFLAGS. the problem is because libecore_evas_la_DEPENDENCIES contains $(ECORE_SDL_LIB), so make considere @SDL_LIBS@ as a TARGET depending on libecore-evas.la. That's why i writted a small patch to fix it, i juste moved @SDL_LIBS@ from ECORE_SDL_LIB to libecore_evas_la_LIBADD var. you'll can have a look in my patch. mrpouet. - 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] EFL and Webkit
On Mon, 10 Mar 2008 06:31:51 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: I have a question for you on this though: I imagined having 'native surface' image obj api given in each of the engine headers, but you added a generic evas api for it.. What exactly do you have in mind here? eg. say with gl-textures? literally evas exposing the engine drawing routines for that engine - generalised tho. gl i would expose as a generic api from a evas-3d lib on top of a native surface, but it would just abstrait to either software mesa or direct hardware opengl, so it'd work in a software canvas, just slowly. Ummm I'm not sure I follow you here at all. What you've mentioned above seems far more reaching - not quite just dealing with implementing image obj 'native surfaces', which is what I was wondering about here. Maybe the other engine-ers (Cedric, Vincent, Gustavo) can give their own views here as well, but let me just be a bit more specific as to how I'd imagined this and see if it makes sense. engines have draw functions, like draw line draw polygon draw image (src rect, dest rect, scale mode) traw text with font X etc. etc. - these are internal between evas's canvas core and the engines. this is not exposed. if a smart object or Custom evas object can have access to these to draw - then either they can draw to a surface (image) using them OR they can draw directly to the canvas when an update render happens (and they get their paint() callback called - doesn't exist now, but hypothetically). By 'native surfaces' I'd meant things like xrender pictures, gl textures (maybe pbuffers), sdl surfaces, etc. So, more like engine- renderer specific 'buffer surfaces'. yup. One'd then have get/set functions for image objs of 'similar' evas engines (xrender-x11, gl-x11,...), along with various specialty funcs to query whatever extra stuff specific such 'surfaces' might have (eg. wether a gl texture is an nv-rect, its actual size, etc). Ideally, there would also be given a means to convert such surfaces to argb data (wether exposed or just internal). all images at some point use a native surface. software engines share the native surface with the original argb pixel data :) I'd imagined these funcs in each engine header, nothing at all in the general evas api, and one would implement the funcs in the engine modules, likely via the use of a new 'object function' to get an evas object's 'engine_data'. Or at least, that's more or less what I envisioned for these. Then go from there and build things like an evas-3D lib if desired.. possibly dependent on gl but able to render to any evas by say rendering to a gl buffer and getting argb data if need be, or some other way.. But what I was curious about was what exactly you had in mind with your: typedef struct _Evas_Native_Surface Evas_Native_Surface; /** A generic datatype for engine specific native surface information */ EAPI void evas_object_image_native_surface_set(Evas_Object *obj, Evas_Native_Surface *surf); EAPI Evas_Native_Surface * evas_object_image_native_surface_get(Evas_Object *obj); for example. if it's the GL engine u can set a GL texture ID directly as the image native surface (u will need to provide extra info like width/height, has alpha etc. in a small wrapper struct), or a pixmap / xrender picture for x11 (again need to provide some extra info like visual, format etc.). so evas will then take the target-specific native surface and just use it as if evas owned/created it itself. this is how u'd do a composite manager - xrender engine, you pass it pixmaps/xrender pictures for native sruface as images, you swallow images into containers and control them. on damage events u add update regions to the image. evas does the rest. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] [PATCH] more works and fixes for wallpaper fetcher
On Fri, 21 Mar 2008 17:21:35 +0100 Massimiliano Calamelli [EMAIL PROTECTED] babbled: 2008/3/21, Sebastian Dransfeld [EMAIL PROTECTED]: Why not just use libxml2 and make the wallpaper_web part optional if the user has libxml2? Sebastian I agree, and your idea already are in TODO list, but i don't started with it for some reasons. The module is a testbed to see how online stuffs can be improve E's life, so imho I have to work to make it usable without problems; after do that, and after seeing what people think about, we can start with another external application that get online stuffs for themes, icons, wallpapers, cursors, etc. This kind of app must have a solid backend library to use to get/put online contents, built by libxmle/exml/whatever. Atm i prefer to work to make my module useful instead of change the parser to use another library (that i've to study), having in mind that there's an entry for this kind of lib in GSoC ideas page. maybe it's just me, but as we control both the server-side AND the app - do we NEED to use XML and RSS feeds? why do we need to make a complicated format to parse where we are arguing over adding libraries just to parse it, when we COULD simplify it to a VERY simple format. eg: (get http://www.get-e.org/e-feeds/wallpapers.feed) result: -ITEM- Name: The name of the item Updated: 2432215534 Thumb: wallpapers/thumbs/blah.png File: wallpapers/files/blah.edj -ITEM- Name: Another item ... (thumb and file paths are relative to http://www.get-e.org/e-feeds/ - i.e. the dir the .feed file is in, Updated is just a timestamp in seconds since jan 1 1970). this would be brain-dead simple to parse, to generate etc. just a suggestion - but i just think there is a lot of debate and work when we can SAVE effort by just thinking simple. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] Systray - Ideas for a new spec
On Mon, 10 Mar 2008 15:25:45 +0100 lok [EMAIL PROTECTED] babbled: i agree with a lot of your points here. i've made them myself. the problem is people keep asking for systray support because apps go and USE/ABUSE it and they want that abuse supported. we can party support it in some ways so its functional but doesn't quite work until apps change their usage a bit. Hi, I took time to talk to this subject because I wanted to write my proof of concept before replying. In my opinion, a systray is a bad idea. For the last two weeks I kept asking myself, Why do people want a systray ? What exactly is a systray ? How can I provide it ?. For the first question I've directly asked to anybody I know was using trayer, or wanted a tray on E. The answers were about having a way to be notified, a quick way to show/hide some windows. A few were about using direct actions and each time with the same example, an audio player. And the last one that nobody say directly but somehow is always there, because they are simply used to it. For the second question, the easiest way to find out what exactly is a systray, it's to look at the source. A systray on windows is the only way to move an app outside the taskbar, the only way to keep visible an application running in the background but needs a GUI sometimes and was the only way to provide a pseudo gadget. Nowadays a huge amout of applications running on windows put something in the tray. Most of the time the systray have more applications than the taskbar, and 3/4 of them being hidden to take less place within the bar (so much for the monitoring). So what exactly is a systray ? I dunno, if it's a way to continuously notify why hide the icons and show a bubble ? If it's a way to lighten the taskbar why only the application as the power to choose ? And if it's a way to provide quick actions why do we still need this under our WMs were any one of them can use modules for years ? Well, here is the problem. A systray is a mess in it's basic design. Some half done thing wishing to compete with OS X dock. So write a spec, even good, about something doing a bit of (continuous ?) notification, a bit of quick action and a bit of docking isn't, in my opinion, the greatest thing to do. Of course it will works, but why redo half of the job instead of finishing it once and for all ? First let's have a _real_ fdo specification about notifications, galago's one was refused. It still miss some details, but I think it's a good base. And I believe it's something far more useful than just a common way to blink an icon somewhere in the screen (the urgent flag can already be used to do it). By pushing it a little I did the notification boxes : http://lok.eadrax.org/images/notification_box-3.png http://lok.eadrax.org/images/notification_box-4.png Which means than a good notification spec could cover all the aspect of notifications, popups and icons. Moreover I didn't implemented it but this spec handle actions, their purpose is to reply to an event. A docking specification doesn't seems necessary, we already have everything we need to dock an application like it would be in a tray. IIirk is the proof and IBox is also a solution. And finally for quick actions there is no common way possible. Depending on the purpose of the applications you will not wish to display it the same way. For an audio player, having a module giving you the possibility to play/pause/next/prev with a single click is better than openning a menu and choosing the good action in it. See http://www.kuliniewicz.org/music-applet/ for example. Whereas to quickly change a network like with network-manager you would rather have a popup with a list showing directly the name of the network, if it's protected and how good you catch it. All that using the same look than your WM. Redoing a module for each WM takes more work but end up nicer than reducing everything to a menu. Mixing iiirk and notification together would provide over 90% of what a tray does. Add to that IBar/IBox and you get something near OS X dock. Of course any other combination is possible. All this relying only on the .desktop spec, a notification one and the old NetWM's skip flags, breaking nothing and just requiring sometimes to install a notification plugin. So no I don't think we should change the tray spec, we should forget about it. Even if we do change it, even if we also manage to make the applications following the new one. All we will get is a bunch of icons stacked at their own will in a corner with the ability to open a menu. I would rather like to see a clean and complete notification spec accepted by FDO. Samuel 'lok' Mendes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
Re: [E-devel] Evas Object Size Hints: draft
On Fri, 21 Mar 2008 05:28:19 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: even as a draft, i think this is good enough to go in. i'm sticking it in. we can add things in cvs :) On Fri, Mar 21, 2008 at 5:25 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Guys, Here is my first draft to add size hints to Evas_Object, this is just about the basics and contain no code to calculate size based on hints, interceptors to enforce size and like. What I want to know: - Is it ok to have just one EVAS_CALLBACK_CHANGED_SIZE_HINTS or it's better to go with one callback for each of the fields. I think that's an overkill. - I used aspect to match Edje, is it enough for every other possible user? It does have an enumeration with aspect control and 2 integers: width and height. - Are you Ok with the names? - Something else is missing? After these are ok I'll go to implement a method to calculate size based on given size (or maybe it's better to use current size?) and the size hints. This would be like Edje does now and in future will have Edje to use it. Then to implement an interceptor to use when you want to enforce these sizes. Damn, the file was sent as octet-stream by firefox and was removed by mailman... now again as text/plain -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] backtrace
On Fri, 28 Mar 2008 20:51:34 +0100 Massimo Maiurana [EMAIL PROTECTED] babbled: that's the nature of memory corruption - something is stamping on random bits of memory - why, we don't know, and what is doing it, but it may stamp on something different each time and the resulting segv at a later time is different of course. Carsten Haitzler (The Rasterman), il 22/03/2008 14:27, scrisse: mmory has been corrupted - something forecast does has walked over memory that shouldnt be touched. what it is i don't know and would probably need a code review of the forecast module code. attached another backtrace, this time the error looks quite different. I can confirm that there are no segfaults when forecasts isn't loaded. -- Massimo Maiurana massimoatragusa.linux.it http://massimo.solira.org GPG keyID #7044D601 Articolo 11 - L'Italia ripudia la guerra come strumento di offesa alla libertà degli altri popoli e come mezzo di risoluzione delle controversie internazionali -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] [PATCH] more works and fixes for wallpaper fetcher
On Mon, 17 Mar 2008 14:34:03 +0100 Massimiliano Calamelli [EMAIL PROTECTED] babbled: patch in cvs. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, the attached diff contains more works and a little fixes for wallpaper fetcher. Small changelog: * changes in variable names, make it more sense * switch from framelist to frametable, to add entry and button widget * feed parsing engine rewritten from scratch, now it run fast and support RSS with MEDIA namespace (xmlns:media) * now user can get images from Flickr just entering a text * added a little TODO Now i'm looking for a way to allow user to add/remove feeds. What is the right place? Inside E config? External eet? Plz review, and if it sounds good feel free to apply! Thx Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH3nNNleGEL56NNP4RArY7AJ9uMXaJBnpjAEzTDKFDyNOJvRDAMgCeNo30 g5LPFIkeg7SPKGFM6fpG2mY= =3bZN -END PGP SIGNATURE- -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] [PATCH] evas-framebuffer.pc.in rename
On Fri, 11 Apr 2008 16:27:18 +0200 (CEST) Vincent Torri [EMAIL PROTECTED] babbled: On Mon, 7 Apr 2008, Lars Munch wrote: Hi Unfortunately the addition off expedite_check_engine.m4 in expedite broke the detection of the framebuffer engine in expedite. The course of this is an inconsistent naming of the file evas-framebuffer.pc.in which should be named evas-fb.pc.in to be consistent with the other engine names. can't we just modify what is checked in expedite ? That is configure.in, a Makefile.am and 1 or 2 files. consistency does make sense :) The attached patch renames this file an changes Configure.in and Makefile.am in ecore and evas accordingly. A quick grep in the cvs repository indicates that expedite is the only project that actually uses evas-framebuffer.pc, so the breakage of applying this patch should be minimal. Regards Lars Munch -- 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. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] [PATCH] evas-framebuffer.pc.in rename
On Mon, 7 Apr 2008 18:31:02 +0200 [EMAIL PROTECTED] (Lars Munch) babbled: Hi Unfortunately the addition off expedite_check_engine.m4 in expedite broke the detection of the framebuffer engine in expedite. The course of this is an inconsistent naming of the file evas-framebuffer.pc.in which should be named evas-fb.pc.in to be consistent with the other engine names. The attached patch renames this file an changes Configure.in and Makefile.am in ecore and evas accordingly. A quick grep in the cvs repository indicates that expedite is the only project that actually uses evas-framebuffer.pc, so the breakage of applying this patch should be minimal. in cvs :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] [PATCH] Ecore Timer
On Mon, 7 Apr 2008 14:15:15 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: This patch add the possibility to delay a timer and to know the pending time before the next wake up. They should not affect any current code using the timer. in cvs :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] [PATCH] The big cache patch.
On Mon, 7 Apr 2008 21:02:53 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: in cvs - lets test. so far working ok. if any issues - we'll fix them. Hi, Let's really break everything ! This is the same serie of old patch up to date that improve the cache system. It should not break anything. The code is cleaner and should fix some bugs hard to track in the current code base. I want to base my work on loading image in the background on this code. So I would like people to take time to test, check their application with it and report bugs to me. Have fun, Cedric PS: Some engine (typically the one I can't compile like windows one) will not be up to date. -- Cedric BAIL -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] [RFC] Async events API
On Tue, 8 Apr 2008 14:02:50 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
On Tue, Apr 8, 2008 at 11:05 AM, Cedric BAIL [EMAIL PROTECTED] wrote:
Hi,
This patch doesn't break anything at this time :-) It's a
standalone feature that just add the possibility to evas to receive
events from another thread. It introduce 3 new API.
I'm not sure the fd must be set to non-block, this might cause more
trouble than good. I'd make it blocker for now and handle things
properly using select(), or believe that when the file descriptor is
ready to read (from ecore_fd_main...) we can read everything (ie: no
partial writes, no threads will die with incomplete writes).
non-block is fine. that's what select() is for :) read the fd while there are
things to read - then stop and let select tell u more is there to read. this fd
is to let evas wake up the calling program for an event that happened
asynchronously - so that's all we need. it really only needs to write 1 word or
byte down the pipe as a signal. personally i'd write a void * (pointer) that is
a pointer to a message (struct) of some sort. a standard one. it is the
reader's job to take the struct, pass it on to some handler and free it when
done. posting events is just a matter of waking the process up. you want to do
this for example when an image has finished decoding (maybe if u want
progressive load u do it multiple times during load). this is very useful. :)
* Retrieve the fd that need to be monitored by ecore :
EAPI int evas_async_events_fd_get();
missing (void)
yeah. :)
* Process all pending event in the pipe (This function could be called
without any event in the pipe) :
EAPI int evas_async_events_process();
missing (void), also true for init, shutdown...
also, do ... while (check == sizeof(current)) logic is wrong, you
should check += read(..., todo) and also change where to load the
rest of it.
Actually I would rewrite it as:
int todo = sizeof(current);
char *p = (char *)current;
do
{
int n;
n = read(_fd_read, p, todo);
if (n == -1)
{
if (errno == EAGAIN || errno == EINTR)
continue;
else
HANDLE_ERROR();
}
todo -= n;
p += n;
} while (todo 0)
* Push an event inside the pipe from another thread :
EAPI Evas_Bool evas_async_events_put(Evas_Object *obj,
Evas_Callback_Type type, void *event_info);
Write logic is also wrong.
new + offset
given that new is of type Evas_Event_Async is not what you want. This
pointer arithmetic is like vector indexing, so it would be like:
new[offset]
You need to cast it to some type that is the size of a byte, like char:
((char *)new) + offset
is fine. But I would rewrite it like I did for read.
I currently don't have any code using it, but I plan to use this for
the coming background loading of image. So please review it.
done :-)
I'm not sure about evas_init() doing this. Nothing against it, but
maybe some purist wouldn't like to have pthread mutexes created.
i would make this optional. if u are never going to use async stuff - it should
just do nothing. the fd should just never wake up, or what is done in a thread
can be just done in-line and the wakeup can be emulated.
--
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
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
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
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
-
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] [PATCH] edje: remove unused fnmatch.h include
On Fri, 11 Apr 2008 14:06:37 +0200 [EMAIL PROTECTED] (Lars Munch) babbled: fnmatch is not used in edje anymore. Attached trivial patch removes the last traces of its existence in edje. good point. in cvs! -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] Draw multiline text with textblock.
On Thu, 10 Apr 2008 22:12:37 +0900 Karthik [EMAIL PROTECTED] babbled: Dear all, Can anyone please guide me on how to display multiline text with \n in a textblock. Currently I am replacing \n with br tag and converting it to a newline character using style text. u'd have to insert text into tb manually not using markup. u need to add text then add a format node for the newlines. Thanks in Advance Karthik - 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] [PATCH] batget - problem with battery removal in sysfs mode
Hi,
batgets cpu usage goes up to 100% after resuming.
During resume the sysfs entry for the battery briefly disappears, same
when I take it out. I don't know if that is normal behavior
or if my laptop is just weird..
It gets stuck in this loop while attempting to read from it:
line 454:
for (;;)
{
char buf[1024];
int num;
if ((num = read(sysev-fd, buf, sizeof(buf))) 1)
{
lost = ((errno == EIO) ||
(errno == EBADF) ||
(errno == EPIPE) ||
(errno == EINVAL) ||
(errno == ENOSPC));
if (num == 0) break;
}
}
Errno is set to ENODEV and read() returns -1 on error so it never leaves
that loop.
e_battery_stuckage.diff causes batget to stop monitoring the battery
if the file disappears.
e_battery_dbus_sysfs.diff allows batget to monitor battery presence via
dbus/hal. I've never done anything with dbus or efl, and my C knowledge
is a bit shaky so this may not be completely correct. It seems to work
fine here though.
stefan
--- src_old/modules/battery/batget.c 2008-04-12 02:45:18.0 +0200
+++ src/modules/battery/batget.c 2008-04-12 02:45:28.0 +0200
@@ -462,8 +462,9 @@
(errno == EBADF) ||
(errno == EPIPE) ||
(errno == EINVAL) ||
- (errno == ENOSPC));
- if (num == 0) break;
+ (errno == ENOSPC) ||
+ (errno == ENODEV));
+ if (num = 0) break;
}
}
if (lost)
--- src_old/modules/battery/batget.c 2008-04-12 02:48:46.0 +0200
+++ src/modules/battery/batget.c 2008-04-12 02:49:04.0 +0200
@@ -410,10 +410,15 @@
static void linux_sys_class_power_supply_check(void);
typedef struct _Sys_Class_Power_Supply_Uevent Sys_Class_Power_Supply_Uevent;
+static void linux_sys_class_power_supply_sysev_init(Sys_Class_Power_Supply_Uevent *sysev);
+static int linux_sys_class_powe_supply_cb_delay_check(void *data);
+
#define BASIS_CHARGE 1
#define BASIS_ENERGY 2
#define BASIS_VOLTAGE 3
+#define UDI_BAT_HEAD /org/freedesktop/Hal/devices/computer_power_supply_battery_
+
struct _Sys_Class_Power_Supply_Uevent
{
char *name;
@@ -433,6 +438,89 @@
static Ecore_List *events = NULL;
static Ecore_Timer *sys_class_delay_check = NULL;
+
+static void
+linux_sys_class_power_supply_battery_add(char * name)
+{
+ char buf[4096];
+ Sys_Class_Power_Supply_Uevent *sysev;
+
+ sysev = E_NEW(Sys_Class_Power_Supply_Uevent, 1);
+ sysev-name = strdup(name);
+ snprintf(buf, sizeof(buf), /sys/class/power_supply/%s/uevent, name);
+ sysev-fd = open(buf, O_RDONLY);
+ if (sysev-fd = 0)
+ sysev-fd_handler = ecore_main_fd_handler_add(sysev-fd,
+ ECORE_FD_READ,
+ linux_sys_class_power_supply_cb_event_fd_active,
+ sysev,
+ NULL, NULL);
+ ecore_list_append(events, sysev);
+ linux_sys_class_power_supply_sysev_init(sysev);
+}
+
+static void
+linux_sys_class_power_supply_battery_remove(char * name)
+{
+ Sys_Class_Power_Supply_Uevent *sysev;
+
+ ecore_list_first_goto(events);
+ while ((sysev = ecore_list_next(events)))
+{
+ if (!strcasecmp(name, sysev-name))
+ {
+ ecore_list_remove(events);
+ if (sysev-fd_handler)
+ ecore_main_fd_handler_del(sysev-fd_handler);
+ if (sysev-fd = 0) close(sysev-fd);
+ free(sysev-name);
+ free(sysev);
+
+ return;
+ }
+}
+}
+
+#ifdef HAVE_EDBUS
+
+static void
+linux_sys_class_power_supply_dbus_cb(void * data, DBusMessage *msg)
+{
+ DBusError err;
+ char* udi;
+ int offset = strlen(UDI_BAT_HEAD);
+
+ dbus_error_init(err);
+ dbus_message_get_args(msg, err, DBUS_TYPE_STRING, udi, DBUS_TYPE_INVALID);
+ if (dbus_error_is_set(err))
+ {
+ dbus_error_free(err);
+ return;
+ }
+
+ if (!strncmp(udi, UDI_BAT_HEAD, offset))
+ {
+ if (strlen(udi) offset strlen(udi) offset + 4096)
+ {
+ char name[4096];
+ const char *member = dbus_message_get_member(msg);
+
+ strcpy(name, udi+offset);
+
+ if (!strcmp(member, DeviceAdded))
+ {
+ linux_sys_class_power_supply_battery_add(name);
+ }
+ else
+ {
+ linux_sys_class_power_supply_battery_remove(name);
+ }
+ }
+ }
+}
+
+#endif
+
static int
linux_sys_class_powe_supply_cb_delay_check(void *data)
{
@@ -588,7 +676,6 @@
{
Ecore_List *bats;
char *name;
- char buf[4096];
bats = ecore_file_ls(/sys/class/power_supply/);
if (bats)
@@ -596,21 +683,8 @@
events = ecore_list_new();
while ((name = ecore_list_next(bats)))
{
- Sys_Class_Power_Supply_Uevent *sysev;
-
if (strncasecmp(bat, name, 3)) continue;
- sysev = E_NEW(Sys_Class_Power_Supply_Uevent, 1);
- sysev-name = strdup(name);
- snprintf(buf, sizeof(buf), /sys/class/power_supply/%s/uevent, name);
- sysev-fd = open(buf, O_RDONLY);
- if (sysev-fd = 0)
- sysev-fd_handler = ecore_main_fd_handler_add(sysev-fd,
- ECORE_FD_READ,
- linux_sys_class_power_supply_cb_event_fd_active,
-
[E-devel] Latest evas is missing files
With the latest evas (from [EMAIL PROTECTED]:30 PST) I receive the following error: $ NOCONFIGURE=ON ./autogen.sh Running aclocal... /usr/share/aclocal/libole2.m4:18: warning: underquoted definition of AM_PATH_LIBOLE2 /usr/share/aclocal/libole2.m4:18: run info '(automake)Extending aclocal' /usr/share/aclocal/libole2.m4:18: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Running autoheader... Running autoconf... Running libtoolize... Running automake... configure.in:11: installing `./install-sh' configure.in:11: installing `./missing' src/lib/Makefile.am: installing `./depcomp' src/lib/engines/Makefile.am:4: required directory src/lib/engines/common_16 does not exist src/modules/engines/Makefile.am:3: required directory src/modules/engines/software_16_sdl does not exist configure.in:1578: required file `src/lib/engines/common_16/Makefile.in' not found configure.in:1578: required file `src/modules/engines/software_16_sdl/Makefile.in' not found This was working earlier today before the latest changes. Thanks, -sandalle -- Eric Sandall | Source Mage GNU/Linux Developer [EMAIL PROTECTED] PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | http://counter.li.org/ #196285 signature.asc Description: This is a digitally signed message part. - 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] Latest evas is missing files
On Fri, 11 Apr 2008 18:42:53 -0700 Eric Sandall [EMAIL PROTECTED] babbled: fixed :) With the latest evas (from [EMAIL PROTECTED]:30 PST) I receive the following error: $ NOCONFIGURE=ON ./autogen.sh Running aclocal... /usr/share/aclocal/libole2.m4:18: warning: underquoted definition of AM_PATH_LIBOLE2 /usr/share/aclocal/libole2.m4:18: run info '(automake)Extending aclocal' /usr/share/aclocal/libole2.m4:18: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Running autoheader... Running autoconf... Running libtoolize... Running automake... configure.in:11: installing `./install-sh' configure.in:11: installing `./missing' src/lib/Makefile.am: installing `./depcomp' src/lib/engines/Makefile.am:4: required directory src/lib/engines/common_16 does not exist src/modules/engines/Makefile.am:3: required directory src/modules/engines/software_16_sdl does not exist configure.in:1578: required file `src/lib/engines/common_16/Makefile.in' not found configure.in:1578: required file `src/modules/engines/software_16_sdl/Makefile.in' not found This was working earlier today before the latest changes. Thanks, -sandalle -- Eric Sandall | Source Mage GNU/Linux Developer [EMAIL PROTECTED] PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | http://counter.li.org/ #196285 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] Latest evas is missing files
On Friday 11 April 2008 19:10:43 Carsten Haitzler wrote: On Fri, 11 Apr 2008 18:42:53 -0700 Eric Sandall [EMAIL PROTECTED] babbled: fixed :) evas now passes that point (thanks! :)), but now hits: ... Making all in common_16 make[5]: Entering directory `/usr/src/evas-cvs/src/lib/engines/common_16' /bin/sh ../../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../.. -I. -I../../../../src/lib -I../../../../src/lib/include - I/usr/include/freetype2 -march=nocona -m32 -pipe -DPIC -fPIC -O3 -MT evas_soft16_dither_mask.lo -MD -MP -MF .deps/evas_soft16_dither_mask.Tpo -c -o evas_soft16_dither_mask.lo evas_soft16_dither_mask.c gcc -DHAVE_CONFIG_H -I. -I../../../.. -I. -I../../../../src/lib - I../../../../src/lib/include -I/usr/include/freetype2 -march=nocona -m32 -pipe -DPIC -fPIC -O3 -MT evas_soft16_dither_mask.lo -MD -MP -MF .deps/evas_soft16_dither_mask.Tpo -c evas_soft16_dither_mask.c -fPIC -DPIC -o .libs/evas_soft16_dither_mask.o evas_soft16_dither_mask.c:1:32: error: evas_common_soft16.h: No such file or directory evas_soft16_dither_mask.c:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'dither_table' evas_soft16_dither_mask.c:141: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' evas_soft16_dither_mask.c:190: error: expected ';', ',' or ')' before '*' token evas_soft16_dither_mask.c:216: error: expected ')' before '*' token evas_soft16_dither_mask.c:231: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' evas_soft16_dither_mask.c:257: error: expected ';', ',' or ')' before '*' token evas_soft16_dither_mask.c:282: error: expected ')' before '*' token make[5]: *** [evas_soft16_dither_mask.lo] Error 1 make[5]: Leaving directory `/usr/src/evas-cvs/src/lib/engines/common_16' make[4]: *** [all-recursive] Error 1 -sandalle -- Eric Sandall | Source Mage GNU/Linux Developer [EMAIL PROTECTED] PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | http://counter.li.org/ #196285 signature.asc Description: This is a digitally signed message part. - 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] [RFC] Async events API
On Fri, Apr 11, 2008 at 9:43 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 8 Apr 2008 14:02:50 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Tue, Apr 8, 2008 at 11:05 AM, Cedric BAIL [EMAIL PROTECTED] wrote: Hi, This patch doesn't break anything at this time :-) It's a standalone feature that just add the possibility to evas to receive events from another thread. It introduce 3 new API. I'm not sure the fd must be set to non-block, this might cause more trouble than good. I'd make it blocker for now and handle things properly using select(), or believe that when the file descriptor is ready to read (from ecore_fd_main...) we can read everything (ie: no partial writes, no threads will die with incomplete writes). non-block is fine. that's what select() is for :) read the fd while there are things to read - then stop and let select tell u more is there to read. this fd is to let evas wake up the calling program for an event that happened asynchronously - so that's all we need. it really only needs to write 1 word or byte down the pipe as a signal. personally i'd write a void * (pointer) that is a pointer to a message (struct) of some sort. a standard one. it is the reader's job to take the struct, pass it on to some handler and free it when done. posting events is just a matter of waking the process up. you want to do this for example when an image has finished decoding (maybe if u want progressive load u do it multiple times during load). this is very useful. :) I also agree with just using pipe to wakeup, but I'd go with a byte. Problem is that if we read more data from a non-blocking fd, then we might end with partial reads, then we must keep this somewhere for future readings... THAT's a problem and that's painful to get right with non-blocking, if we don't take care, bugs may show and they would be hard to track. Bytes are atomic there, just read one byte, pop from the queue and process, then read another, pop, process... I'm not sure about evas_init() doing this. Nothing against it, but maybe some purist wouldn't like to have pthread mutexes created. i would make this optional. if u are never going to use async stuff - it should just do nothing. the fd should just never wake up, or what is done in a thread can be just done in-line and the wakeup can be emulated. make what optional, and where? Make it whole async stuff compile-time optional? -- 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] [RFC] Async events API
On Fri, 11 Apr 2008 23:28:29 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Fri, Apr 11, 2008 at 9:43 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 8 Apr 2008 14:02:50 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Tue, Apr 8, 2008 at 11:05 AM, Cedric BAIL [EMAIL PROTECTED] wrote: Hi, This patch doesn't break anything at this time :-) It's a standalone feature that just add the possibility to evas to receive events from another thread. It introduce 3 new API. I'm not sure the fd must be set to non-block, this might cause more trouble than good. I'd make it blocker for now and handle things properly using select(), or believe that when the file descriptor is ready to read (from ecore_fd_main...) we can read everything (ie: no partial writes, no threads will die with incomplete writes). non-block is fine. that's what select() is for :) read the fd while there are things to read - then stop and let select tell u more is there to read. this fd is to let evas wake up the calling program for an event that happened asynchronously - so that's all we need. it really only needs to write 1 word or byte down the pipe as a signal. personally i'd write a void * (pointer) that is a pointer to a message (struct) of some sort. a standard one. it is the reader's job to take the struct, pass it on to some handler and free it when done. posting events is just a matter of waking the process up. you want to do this for example when an image has finished decoding (maybe if u want progressive load u do it multiple times during load). this is very useful. :) I also agree with just using pipe to wakeup, but I'd go with a byte. Problem is that if we read more data from a non-blocking fd, then we might end with partial reads, then we must keep this somewhere for future readings... THAT's a problem and that's painful to get right with non-blocking, if we don't take care, bugs may show and they would be hard to track. Bytes are atomic there, just read one byte, pop from the queue and process, then read another, pop, process... no need to make it blocking :) look at ecore_con - hell look at emotion. it's all done with non-blocking. for emotion i used void *'s to write that point to he message. it works by handing the pointer to a msg struct from the slave thread to the main one - it's quite handy that way. it's also generic as i can pass anything along from a slave to a master thread - just point to it :) the difference between a byte and a void * won't really be anything worth talking about as u are unlikely to pass 1000's of them at a time - even if u do, kernel buffers are 128k by default - that's 32k messages on 32bit and 16k on 16bit that u can buffer before draining... that's a LOOOT. I'm not sure about evas_init() doing this. Nothing against it, but maybe some purist wouldn't like to have pthread mutexes created. i would make this optional. if u are never going to use async stuff - it should just do nothing. the fd should just never wake up, or what is done in a thread can be just done in-line and the wakeup can be emulated. make what optional, and where? Make it whole async stuff compile-time optional? no - the async fd is there, but the operation is not done in a thread. the load is done syncronously at load time if async stuff is disabled. u just need to have infrastructure where u can set a callback to be executed async - it will be (and then message back the event fd with a message when it's done) *IF* async evas stuff is enabled (enable by default), *IF it's not enabled, the callback will be called at the time you start the async operation (i.e at the time u begin the load). t5his means the load call, so to speak, will block and be slow until the async callback finishes, if async is disabled, and if enabled, it won't block. in both situations your async fd will wake up with an event you process later :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] Latest evas is missing files
On Fri, 11 Apr 2008 19:20:07 -0700 Eric Sandall [EMAIL PROTECTED] babbled: fixed that now too. On Friday 11 April 2008 19:10:43 Carsten Haitzler wrote: On Fri, 11 Apr 2008 18:42:53 -0700 Eric Sandall [EMAIL PROTECTED] babbled: fixed :) evas now passes that point (thanks! :)), but now hits: ... Making all in common_16 make[5]: Entering directory `/usr/src/evas-cvs/src/lib/engines/common_16' /bin/sh ../../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../.. -I. -I../../../../src/lib -I../../../../src/lib/include - I/usr/include/freetype2 -march=nocona -m32 -pipe -DPIC -fPIC -O3 -MT evas_soft16_dither_mask.lo -MD -MP -MF .deps/evas_soft16_dither_mask.Tpo -c -o evas_soft16_dither_mask.lo evas_soft16_dither_mask.c gcc -DHAVE_CONFIG_H -I. -I../../../.. -I. -I../../../../src/lib - I../../../../src/lib/include -I/usr/include/freetype2 -march=nocona -m32 -pipe -DPIC -fPIC -O3 -MT evas_soft16_dither_mask.lo -MD -MP -MF .deps/evas_soft16_dither_mask.Tpo -c evas_soft16_dither_mask.c -fPIC -DPIC -o .libs/evas_soft16_dither_mask.o evas_soft16_dither_mask.c:1:32: error: evas_common_soft16.h: No such file or directory evas_soft16_dither_mask.c:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'dither_table' evas_soft16_dither_mask.c:141: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' evas_soft16_dither_mask.c:190: error: expected ';', ',' or ')' before '*' token evas_soft16_dither_mask.c:216: error: expected ')' before '*' token evas_soft16_dither_mask.c:231: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' evas_soft16_dither_mask.c:257: error: expected ';', ',' or ')' before '*' token evas_soft16_dither_mask.c:282: error: expected ')' before '*' token make[5]: *** [evas_soft16_dither_mask.lo] Error 1 make[5]: Leaving directory `/usr/src/evas-cvs/src/lib/engines/common_16' make[4]: *** [all-recursive] Error 1 -sandalle -- Eric Sandall | Source Mage GNU/Linux Developer [EMAIL PROTECTED] PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | http://counter.li.org/ #196285 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] EFL and Webkit
Carsten wrote: But what I was curious about was what exactly you had in mind with your: typedef struct _Evas_Native_Surface Evas_Native_Surface; /** A generic datatype for engine specific native surface information */ EAPI void evas_object_image_native_surface_set(Evas_Object *obj, Evas_Native_Surface *surf); EAPI Evas_Native_Surface * evas_object_image_native_surface_get(Evas_Object *obj); for example. if it's the GL engine u can set a GL texture ID directly as the image native surface (u will need to provide extra info like width/height, has alpha etc. in a small wrapper struct), or a pixmap / xrender picture for x11 (again need to provide some extra info like visual, format etc.). so evas will Yeah, that's what I thought you meant - though there are other interpretations possible (eg. make a gl texture native surface work even with a software-x11 canvas, if glx is available, etc.). then take the target-specific native surface and just use it as if evas owned/created it itself. this is how u'd do a composite manager - xrender engine, you pass it pixmaps/xrender pictures for native sruface as images, you swallow images into containers and control them. on damage events u add update regions to the image. evas does the rest. What do you do if such a native surface is set and one asks for the argb data? What do you do about users setting native surfaces which don't match with the display targets somehow (differing x resources for example). I'd say - restrict native surface api to only have a 'get' func, ie. evas provides a suitable surface for you to draw to, but not for you to 'set' one such...? - 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
