Re: [E-devel] E SVN: raster trunk/edje/src/lib
On Sat, Aug 14, 2010 at 6:03 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: cedric! :) Nah ! Author: raster Date: 2010-08-13 21:03:33 -0700 (Fri, 13 Aug 2010) New Revision: 51108 Modified: trunk/edje/src/lib/edje_load.c Modified: trunk/edje/src/lib/edje_load.c === --- trunk/edje/src/lib/edje_load.c 2010-08-14 04:02:31 UTC (rev 51107) +++ trunk/edje/src/lib/edje_load.c 2010-08-14 04:03:33 UTC (rev 51108) @@ -1263,7 +1263,9 @@ for (i = 0; i img-image.tweens_count; ++i) free(img-image.tweens[i]); - free(img-image.tweens); +// cedric: this array is part of the img struct - no? not separately alloced +// anymore - right? thus shouldnt be free()'d... no? +// free(img-image.tweens); break; } case EDJE_PART_TYPE_EXTERNAL: This bug come from eet and was fixed by last change to it. Update eet and you will see it's gone. And the free is valid here. -- Cedric BAIL -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] eina types and thread safety
Hey Can someone explain me the interest of having the eina data types thread safe ? For me, there is no reason until they are used in the EFL and thread safety is then a requirement (for a reason or another) So, i'm wondering if we should have thread safety in them. It adds more complexity for nothing (it's sufficiently hard to keep the code bugless without that, and it also makes the code more difficult to read) Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore-gtk integration patch
On Thu, 29 Jul 2010 19:56:16 +0900 Mike McCormack mj.mccorm...@samsung.com said: nice optional thingy - in svn. tnx! Hi All, This patch implements the ecore main loop in terms of the GTK main loop, so ecore is a layer on top of glib. Compared the the current glib integration in ecore, this has the added advantage of allowing use of EFL libraries in GTK. thanks, Mike -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] evas BMP loader - fix for 32-bit BMP files saved by GIMP
On Wed, 11 Aug 2010 10:27:58 +0800 Brian Wang brian.wang.0...@gmail.com said: Hello raster, I stole some time and made an app for showing bitmaps in bmpsuite.zip. Please see the PNG screenshot disguised in txt as attached. All bitmaps are shown (properly, i think). gqview seems a bit weaker than evas. :-) And yes, 32-bit bmp is a format i care a lot of since the loading is a lot faster. :-) On a platform with weak computing power, i have to save bits and pieces here and there. If there's no problem, please check my patch and correct it when you see fit. hmm well the text file attached corrupted - cant see it. but... i also created a mini image viewer too for this purpose. as such your patch will break transparent bmp's (100%) which is really an incorrect thing. if you can find a way to make it not incorrect - no problems. i really don't like the fix because of its nature. but what i'm more concerned about is.. why are bmp's faster to load? really? seriously? you've tested? vs what other formats? i really didnt make any effort to make the bmp loader fast. i just implemented it to follow the standards (that's why u find evas's bmp loader beat gqview by a large mile as the gtk one is enferior with standards support than evas's). when i do something i tend to like to do it right. now - you'll need to convince me much more that your hack is a valid patch as it really doesnt follow a standard. what is more of interest to me is the bmp loading being faster than... something else? what is that something else? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 8bpp xcb evas engine
On Wed, 28 Jul 2010 12:54:01 +0200 Alexander Kerner alexander.ker...@googlemail.com said: in svn! :) On Wed, Jul 28, 2010 at 09:15:19AM +0900, Carsten Haitzler wrote: On Wed, 21 Jul 2010 00:19:57 +0200 Alexander Kerner alexander.ker...@googlemail.com said: Hi all, I've implemented the 8bpp grayscale evas engine. It is based on the 16bpp engine. It would be nice if someone could review the code and maybe commit into svn. The patches against evas and ecore are attached. problem with this. you made xcb a requirement for evas to build now... i fixed that. in svn. tnx. Thanks! Attached is a small patch to fix eng_font_draw in software_8. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] efl 1.0.0 - ATTENTION
What: the march to EFL 1.0.0 - first stage ALPHA Covers: eina evas ecore embryo edje efreet e_dbus Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) it's been a while coming. but it's pretty much about time to go to 1.0.0. so what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT sunday august 14th 2010. this is for all of the above libraries (including eet). this means after freeze: * no new features etc. * ONLY documentation fixes * ONLY bug fixes that are tested and work * ONLY formatting and documentation fixes * ONLY build fixes if they don't build or install things in the right place after freeze i'll be going through and removing sonames from libraries. they will also up their so version to 1.0.0. as this is an alpha it is intended to become 1.0.0 directly and the intent between now and 1.0.0 proper is simply fixing bugs (internally) - stuff that doesn't work, has a FIXME to finish it off, etc. - ONLY api breaks we can do from this freeze on until a 1.0.0 proper are absolute emergency ones for when something was really overlooked and we have very little choice. other than that we are on api and abi stability hiatus until full efl 1.0.0 so - you have until midnight saturday GMT (0:00 sunday morning) to finish off your4 last second stuff. if you don't get it in by then... too late. it likely already is too late now anyway. but this is your last hail-mary pass. if you are at a loss for things to do - help fix existing bugs. formatting. README's, cleanliness etc. etc. time to get this show on the road. the clock is ticking. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010 20:36:57 +1000 Carsten Haitzler (The Rasterman) ras...@rasterman.com said: oops - forgot. this means eeze as well for 1.0.0. (yes looking at you stu!) What: the march to EFL 1.0.0 - first stage ALPHA Covers: eina evas ecore embryo edje efreet e_dbus Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) it's been a while coming. but it's pretty much about time to go to 1.0.0. so what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT sunday august 14th 2010. this is for all of the above libraries (including eet). this means after freeze: * no new features etc. * ONLY documentation fixes * ONLY bug fixes that are tested and work * ONLY formatting and documentation fixes * ONLY build fixes if they don't build or install things in the right place after freeze i'll be going through and removing sonames from libraries. they will also up their so version to 1.0.0. as this is an alpha it is intended to become 1.0.0 directly and the intent between now and 1.0.0 proper is simply fixing bugs (internally) - stuff that doesn't work, has a FIXME to finish it off, etc. - ONLY api breaks we can do from this freeze on until a 1.0.0 proper are absolute emergency ones for when something was really overlooked and we have very little choice. other than that we are on api and abi stability hiatus until full efl 1.0.0 so - you have until midnight saturday GMT (0:00 sunday morning) to finish off your4 last second stuff. if you don't get it in by then... too late. it likely already is too late now anyway. but this is your last hail-mary pass. if you are at a loss for things to do - help fix existing bugs. formatting. README's, cleanliness etc. etc. time to get this show on the road. the clock is ticking. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010, Carsten Haitzler (The Rasterman) wrote: What: the march to EFL 1.0.0 - first stage ALPHA Covers: eina evas ecore embryo edje efreet e_dbus Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) it's been a while coming. but it's pretty much about time to go to 1.0.0. so what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT sunday august 14th 2010. this is for all of the above libraries (including eet). this means after freeze: i'm back home on monday and i have plenty of things to do in eina. Mostly fixes, mostly related to windows, but also new features (also for windows). Seriously, announcing such alpha release *just* for the day after is not the cleverest thing you did. Vincent * no new features etc. * ONLY documentation fixes * ONLY bug fixes that are tested and work * ONLY formatting and documentation fixes * ONLY build fixes if they don't build or install things in the right place after freeze i'll be going through and removing sonames from libraries. they will also up their so version to 1.0.0. as this is an alpha it is intended to become 1.0.0 directly and the intent between now and 1.0.0 proper is simply fixing bugs (internally) - stuff that doesn't work, has a FIXME to finish it off, etc. - ONLY api breaks we can do from this freeze on until a 1.0.0 proper are absolute emergency ones for when something was really overlooked and we have very little choice. other than that we are on api and abi stability hiatus until full efl 1.0.0 so - you have until midnight saturday GMT (0:00 sunday morning) to finish off your4 last second stuff. if you don't get it in by then... too late. it likely already is too late now anyway. but this is your last hail-mary pass. if you are at a loss for things to do - help fix existing bugs. formatting. README's, cleanliness etc. etc. time to get this show on the road. the clock is ticking. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010, Vincent Torri wrote: On Sat, 14 Aug 2010, Carsten Haitzler (The Rasterman) wrote: What: the march to EFL 1.0.0 - first stage ALPHA Covers: eina evas ecore embryo edje efreet e_dbus Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) it's been a while coming. but it's pretty much about time to go to 1.0.0. so what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT sunday august 14th 2010. this is for all of the above libraries (including eet). this means after freeze: i'm back home on monday and i have plenty of things to do in eina. Mostly fixes, mostly related to windows, but also new features (also for windows). Seriously, announcing such alpha release *just* for the day after is not the cleverest thing you did. and you also didn't answer about the thread safety in eina. I think it's important. Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010 14:13:06 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Sat, 14 Aug 2010, Vincent Torri wrote: On Sat, 14 Aug 2010, Carsten Haitzler (The Rasterman) wrote: What: the march to EFL 1.0.0 - first stage ALPHA Covers: eina evas ecore embryo edje efreet e_dbus Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) it's been a while coming. but it's pretty much about time to go to 1.0.0. so what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT sunday august 14th 2010. this is for all of the above libraries (including eet). this means after freeze: i'm back home on monday and i have plenty of things to do in eina. Mostly fixes, mostly related to windows, but also new features (also for windows). Seriously, announcing such alpha release *just* for the day after is not the cleverest thing you did. and you also didn't answer about the thread safety in eina. I think it's important. Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Having threadsafe data types is useful for anyone using threads. Out of the people I've asked, nobody has been against adding threadsafe operations; the opposite, everyone has been pro threadsafety as desktop cpus are gaining more cores and thus the ability to efficiently multitask. This is not a null use case. Aside from desktop usage, I am working on bringing EFL into secure server operations, and this requires the use of threads. I realize that not everyone uses threads, which is why threadsafety is in no way required or enabled for normal operation. -- Mike Blumenkrantz Zentific: Our boolean values are huge. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010, Michael Blumenkrantz wrote: Having threadsafe data types is useful for anyone using threads. Out of the people I've asked, nobody has been against adding threadsafe operations; the opposite, everyone has been pro threadsafety as desktop cpus are gaining more cores and thus the ability to efficiently multitask. multitasking ? in the EFL ?? except the internal of evas (which does not require the thread safety for the eina data types), i don't see anywhere else where it is useful. This is not a null use case. Aside from desktop usage, I am working on bringing EFL into secure server operations, and this requires the use of threads. what do you mean by secure server operations ? I realize that not everyone uses threads, which is why threadsafety is in no way required or enabled for normal operation. as the ecore main loop is not thread safe, and almost all the EFL are not thread safe, the interest is almost 0. You could say that with that thread safety, the EFL will be used with other toolkit like gtk or qt. Such thing will never happen, we know that. Such thread safety is not tested well. It means that we maybe have to fix a lot of bugs, while the release is quite soon. If threadd safety is really needed, better adding them after the release. The code is anyway in svn, so it is not lost. Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] evas BMP loader - fix for 32-bit BMP files saved by GIMP
On Sat, Aug 14, 2010 at 6:24 PM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 11 Aug 2010 10:27:58 +0800 Brian Wang brian.wang.0...@gmail.com said: Hello raster, I stole some time and made an app for showing bitmaps in bmpsuite.zip. Please see the PNG screenshot disguised in txt as attached. All bitmaps are shown (properly, i think). gqview seems a bit weaker than evas. :-) And yes, 32-bit bmp is a format i care a lot of since the loading is a lot faster. :-) On a platform with weak computing power, i have to save bits and pieces here and there. If there's no problem, please check my patch and correct it when you see fit. hmm well the text file attached corrupted - cant see it. but... i also created a mini image viewer too for this purpose. as such your patch will break transparent bmp's (100%) which is really an incorrect thing. if you can find a way to make it not incorrect - no problems. i really don't like the fix because of its nature. Well, that's what GIMP does. I guess it's a workaround and it'll be 99.99% accurate since 100% transparent BMPs aren't exactly popular. 32-bit BMPs aren't popular either. If my patch is not ok for the upstream, I'll just keep it private. I'm perfectly ok with it. but what i'm more concerned about is.. why are bmp's faster to load? really? seriously? you've tested? vs what other formats? i really didnt make any effort to make the bmp loader fast. i just implemented it to follow the standards (that's why u find evas's bmp loader beat gqview by a large mile as the gtk one is enferior with standards support than evas's). when i do something i tend to like to do it right. now - you'll need to convince me much more that your hack is a valid patch as it really doesnt follow a standard. what is more of interest to me is the bmp loading being faster than... something else? what is that something else? I haven't benchmarked BMP vs PNG loading speed with Evas. The 'BMP is faster to load' argument is based on various icon-loading (small 32x32 icons) tests I performed on my prior project (ARM920T device @400MHz), which uses SDL/SDL_Image. I think Evas is smarter with images but I just assume loading/render of raw data (BMP) would be faster than with compressed PNG files. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010 14:11:57 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: On Sat, 14 Aug 2010, Carsten Haitzler (The Rasterman) wrote: What: the march to EFL 1.0.0 - first stage ALPHA Covers: eina evas ecore embryo edje efreet e_dbus Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) it's been a while coming. but it's pretty much about time to go to 1.0.0. so what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT sunday august 14th 2010. this is for all of the above libraries (including eet). this means after freeze: i'm back home on monday and i have plenty of things to do in eina. Mostly fixes, mostly related to windows, but also new features (also for windows). Seriously, announcing such alpha release *just* for the day after is not the cleverest thing you did. i have to give a stinging reply. maybe.. JUST maybe.. you should have said something as a reply to my email on august the 7th about an efl 1.0.0 and what is blocking on it. only replies i see from you is about my todo - which i did indeed update. so you had AMPLE warning. thats a week ago. not the smartest thing you ever did forgetting that email was ever sent. :) * no new features etc. * ONLY documentation fixes * ONLY bug fixes that are tested and work * ONLY formatting and documentation fixes * ONLY build fixes if they don't build or install things in the right place after freeze i'll be going through and removing sonames from libraries. they will also up their so version to 1.0.0. as this is an alpha it is intended to become 1.0.0 directly and the intent between now and 1.0.0 proper is simply fixing bugs (internally) - stuff that doesn't work, has a FIXME to finish it off, etc. - ONLY api breaks we can do from this freeze on until a 1.0.0 proper are absolute emergency ones for when something was really overlooked and we have very little choice. other than that we are on api and abi stability hiatus until full efl 1.0.0 so - you have until midnight saturday GMT (0:00 sunday morning) to finish off your4 last second stuff. if you don't get it in by then... too late. it likely already is too late now anyway. but this is your last hail-mary pass. if you are at a loss for things to do - help fix existing bugs. formatting. README's, cleanliness etc. etc. time to get this show on the road. the clock is ticking. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ 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)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, Aug 14, 2010 at 08:36:57PM +1000, Carsten Haitzler wrote: What: the march to EFL 1.0.0 - first stage ALPHA Covers: eina evas ecore embryo edje efreet e_dbus Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) it's been a while coming. but it's pretty much about time to go to 1.0.0. so what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT sunday august 14th 2010. this is for all of the above libraries (including eet). this means after freeze: Could you clarify if this is a freeze for the alpha version or final? E.g. do you plan a snapshot of all parts of EFL for easier testing on various platforms in prepartion for 1.0.0? Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ecore_con threaded recv/send support
Hi,
Was going to commit this, but cedric/bluebugs/etc suggested I send it here
first to get a look over.
Attached is a patch which implements full threading support for ecore_con.
When the ECORE_CON_USE_THREADS flag is passed in server_connect/add, it enables
threaded serving mode. In this mode, all blocking I/O (receiving and sending
on the sockets) spawns a new thread which then pipe writes the data back to
main loop once the operation is complete. This will make all ecore_con
operations and events asynchronous (wrt main loop) when enabled.
In my preliminary tests, this worked flawlessly. I'll write back with some
benchmarks after I get some sleep since I've spent the past 16 hours
(it's now 10am) coding to try and get all of my last minute 1.0 merges in :)
--
Mike Blumenkrantz
Zentific: Our boolean values are huge.
Index: Ecore_Con.h
===
--- Ecore_Con.h (revision 51113)
+++ Ecore_Con.h (working copy)
@@ -161,7 +161,9 @@
/** Use TLS */
ECORE_CON_USE_TLS = (1 6),
/** Attempt to use the previously loaded certificate */
- ECORE_CON_LOAD_CERT = (1 7)
+ ECORE_CON_LOAD_CERT = (1 7),
+ /** Use threads for send/recv operations */
+ ECORE_CON_USE_THREADS = (1 8)
} Ecore_Con_Type;
#define ECORE_CON_USE_SSL ECORE_CON_USE_SSL2
#define ECORE_CON_REMOTE_SYSTEM ECORE_CON_REMOTE_TCP
Index: ecore_con_private.h
===
--- ecore_con_private.h (revision 51113)
+++ ecore_con_private.h (working copy)
@@ -105,6 +105,9 @@
ECORE_MAGIC;
int fd;
Ecore_Con_Type type;
+ Eina_Bool threaded:1;
+ Ecore_Thread *recv_thread;
+ Ecore_Thread *send_thread;
char *name;
int port;
char *path;
Index: ecore_con.c
===
--- ecore_con.c (revision 51113)
+++ ecore_con.c (working copy)
@@ -43,6 +43,8 @@
#include Ecore_Con.h
#include ecore_con_private.h
+typedef struct _Ecore_Con_Thread_Data Ecore_Con_Thread_Data;
+
static void _ecore_con_cb_tcp_connect(void *data, Ecore_Con_Info *info);
static void _ecore_con_cb_udp_connect(void *data, Ecore_Con_Info *info);
static void _ecore_con_cb_tcp_listen(void *data, Ecore_Con_Info *info);
@@ -58,11 +60,25 @@
Ecore_Fd_Handler *fd_handler);
static Eina_Bool _ecore_con_svr_udp_handler(void *data,
Ecore_Fd_Handler *fd_handler);
+
+static void kill_server(Ecore_Con_Server *svr);
+static void _ecore_con_svr_udp_cb(Ecore_Thread *thread, Ecore_Con_Client *cl);
+static void _ecore_con_svr_tcp_cb(Ecore_Thread *thread, Ecore_Con_Client *cl);
+static void _ecore_con_svr_notify(Ecore_Thread *thread, Ecore_Con_Thread_Data *data, Ecore_Con_Client *cl);
+static void _ecore_con_svr_cancel(Ecore_Con_Client *cl);
+
+static void _ecore_con_cl_udp_cb(Ecore_Thread *thread, Ecore_Con_Server *svr);
+static void _ecore_con_cl_tcp_cb(Ecore_Thread *thread, Ecore_Con_Server *svr);
+static void _ecore_con_cl_notify(Ecore_Thread *thread, Ecore_Con_Event_Server_Data *data, Ecore_Con_Server *svr);
+
+
static Eina_Bool _ecore_con_svr_cl_handler(void *data,
Ecore_Fd_Handler *fd_handler);
-static void _ecore_con_server_flush(Ecore_Con_Server *svr);
-static void _ecore_con_client_flush(Ecore_Con_Client *cl);
+static void _ecore_con_server_flush_end(Ecore_Con_Server *svr);
+static void _ecore_con_client_flush_end(Ecore_Con_Client *cl);
+static void _ecore_con_server_flush(Ecore_Thread *thread, Ecore_Con_Server *svr);
+static void _ecore_con_client_flush(Ecore_Thread *thread, Ecore_Con_Client *cl);
static void _ecore_con_event_client_add_free(void *data, void *ev);
static void _ecore_con_event_client_del_free(void *data, void *ev);
@@ -84,6 +100,12 @@
static int _ecore_con_init_count = 0;
int _ecore_con_log_dom = -1;
+struct _Ecore_Con_Thread_Data
+{
+ void *data;
+ int type;
+};
+
/**
* @addtogroup Ecore_Con_Lib_Group Ecore Connection Library Functions
*
@@ -224,6 +246,8 @@
svr-clients = NULL;
svr-ppid = getpid();
ecore_con_ssl_server_prepare(svr);
+ if ((type ECORE_CON_SSL) ECORE_CON_USE_THREADS == ECORE_CON_USE_THREADS)
+ svr-threaded = EINA_TRUE;
type = compl_type ECORE_CON_TYPE;
@@ -333,6 +357,8 @@
svr-clients = NULL;
svr-client_limit = -1;
ecore_con_ssl_server_prepare(svr);
+ if ((type ECORE_CON_SSL) ECORE_CON_USE_THREADS == ECORE_CON_USE_THREADS)
+ svr-threaded = EINA_TRUE;
type = compl_type ECORE_CON_TYPE;
@@ -624,7 +650,8 @@
}
/**
- * Flushes all pending data to the given server. Will return when done.
+ * Flushes all pending data to the given server. Will return when done unless
+ * the server is in threaded mode, in which case it will return immediately.
*
* @param svr The given server.
*/
@@
Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore
On Sat, Aug 14, 2010 at 8:19 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
static int
_ecore_main_select(double timeout)
{
@@ -625,18 +848,10 @@
FD_ZERO(exfds);
/* call the prepare callback for all handlers */
+ _ecore_main_prepare_handlers();
#ifndef HAVE_EPOLL
EINA_INLIST_FOREACH(fd_handlers, fdh)
{
- if ((!fdh-delete_me) (fdh-prep_func))
- {
- fdh-references++;
- fdh-prep_func(fdh-prep_data, fdh);
- fdh-references--;
- }
- }
Is _ecore_main_prepare_handlers() outside of #ifndef HAVE_EPOLL on
purpose now or just a mistake?
How much is this stuff tested? Mike, could you write some simple tests
to fill in ecore test suite?
Lucas De Marchi
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] evas BMP loader - fix for 32-bit BMP files saved by GIMP
On Sat, 14 Aug 2010 21:06:33 +0800 Brian Wang brian.wang.0...@gmail.com said: On Sat, Aug 14, 2010 at 6:24 PM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 11 Aug 2010 10:27:58 +0800 Brian Wang brian.wang.0...@gmail.com said: Hello raster, I stole some time and made an app for showing bitmaps in bmpsuite.zip. Please see the PNG screenshot disguised in txt as attached. All bitmaps are shown (properly, i think). gqview seems a bit weaker than evas. :-) And yes, 32-bit bmp is a format i care a lot of since the loading is a lot faster. :-) On a platform with weak computing power, i have to save bits and pieces here and there. If there's no problem, please check my patch and correct it when you see fit. hmm well the text file attached corrupted - cant see it. but... i also created a mini image viewer too for this purpose. as such your patch will break transparent bmp's (100%) which is really an incorrect thing. if you can find a way to make it not incorrect - no problems. i really don't like the fix because of its nature. Well, that's what GIMP does. I guess it's a workaround and it'll be 99.99% accurate since 100% transparent BMPs aren't exactly popular. 32-bit BMPs aren't popular either. If my patch is not ok for the upstream, I'll just keep it private. I'm perfectly ok with it. sure - though it's once thing being a paining program (gimp) and getting a bmp load of a totally blank bmp wrong and being a generic library that loads images generically for any purpose. gimp can afford to get it wrong without much hassle - it's a bigger problem for evas to get it wrong as the intended usage is much less clearly defined :) but what i'm more concerned about is.. why are bmp's faster to load? really? seriously? you've tested? vs what other formats? i really didnt make any effort to make the bmp loader fast. i just implemented it to follow the standards (that's why u find evas's bmp loader beat gqview by a large mile as the gtk one is enferior with standards support than evas's). when i do something i tend to like to do it right. now - you'll need to convince me much more that your hack is a valid patch as it really doesnt follow a standard. what is more of interest to me is the bmp loading being faster than... something else? what is that something else? I haven't benchmarked BMP vs PNG loading speed with Evas. The 'BMP is faster to load' argument is based on various icon-loading (small 32x32 icons) tests I performed on my prior project (ARM920T device @400MHz), which uses SDL/SDL_Image. I think Evas is smarter with images but I just assume loading/render of raw data (BMP) would be faster than with compressed PNG files. well that depends. you pay a decompress cost - cpu time, but uncompressed (raw) images you pay an IO cost. so which is worse. load 50kb from flash and spend cpu time decompressing... or load 200kb from flash and spend no cpu time decompressing. also with png you can select your compression level and tune things. i suggest you do some actual examining of this with your current target and try png's with various compression levels. you also can use eet to store images (all even in a single file) and then use lossy or lossless compression, as well as zero compression (raw argb). so if performance is an issue - bmp isnt your only option. other formats give you a wider choice. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010, Carsten Haitzler (The Rasterman) wrote: On Sat, 14 Aug 2010 14:11:57 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: On Sat, 14 Aug 2010, Carsten Haitzler (The Rasterman) wrote: What: the march to EFL 1.0.0 - first stage ALPHA Covers: eina evas ecore embryo edje efreet e_dbus Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) it's been a while coming. but it's pretty much about time to go to 1.0.0. so what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT sunday august 14th 2010. this is for all of the above libraries (including eet). this means after freeze: i'm back home on monday and i have plenty of things to do in eina. Mostly fixes, mostly related to windows, but also new features (also for windows). Seriously, announcing such alpha release *just* for the day after is not the cleverest thing you did. i have to give a stinging reply. maybe.. JUST maybe.. you should have said something as a reply to my email on august the 7th about an efl 1.0.0 and what is blocking on it. did you mention the date of the alpha release ? I don't see any. I don't blame you about a release, just that you say that there will be a release tomorrow. One week would have been nice. only replies i see from you is about my todo - which i did indeed update. so you had AMPLE warning. yes. But no date. thats a week ago. not the smartest thing you ever did forgetting that email was ever sent. :) i've not forgotten it. Btw, the only thing i mention and that can block (imo only) is the thread safe stuff. Which happended very recently. Other things i mentioned are mostly related to windows. And as i said in irc, i was away during one month. No possible commit for me since mid july. Otherwise there would have been a lot of things i would have modified. Did you forgot that ? The way the release is done is just random. I really prefered Gustavo's way: a plan put somewhere in the wiki. At least we were warned long before, with precise dates. Vincent * no new features etc. * ONLY documentation fixes * ONLY bug fixes that are tested and work * ONLY formatting and documentation fixes * ONLY build fixes if they don't build or install things in the right place after freeze i'll be going through and removing sonames from libraries. they will also up their so version to 1.0.0. as this is an alpha it is intended to become 1.0.0 directly and the intent between now and 1.0.0 proper is simply fixing bugs (internally) - stuff that doesn't work, has a FIXME to finish it off, etc. - ONLY api breaks we can do from this freeze on until a 1.0.0 proper are absolute emergency ones for when something was really overlooked and we have very little choice. other than that we are on api and abi stability hiatus until full efl 1.0.0 so - you have until midnight saturday GMT (0:00 sunday morning) to finish off your4 last second stuff. if you don't get it in by then... too late. it likely already is too late now anyway. but this is your last hail-mary pass. if you are at a loss for things to do - help fix existing bugs. formatting. README's, cleanliness etc. etc. time to get this show on the road. the clock is ticking. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ 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)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
Hey raster, What's the scheduled date of the end of the freeze? Thanks, Tom. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010 16:16:45 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: i'm back home on monday and i have plenty of things to do in eina. Mostly fixes, mostly related to windows, but also new features (also for windows). Seriously, announcing such alpha release *just* for the day after is not the cleverest thing you did. i have to give a stinging reply. maybe.. JUST maybe.. you should have said something as a reply to my email on august the 7th about an efl 1.0.0 and what is blocking on it. did you mention the date of the alpha release ? I don't see any. I don't blame you about a release, just that you say that there will be a release tomorrow. One week would have been nice. only replies i see from you is about my todo - which i did indeed update. so you had AMPLE warning. yes. But no date. why did it need a date? i asked what is left blocking? you stayed mum about it for a week. i didn't ask for your own task schedule and dates - simply what is there left to do? - no mention of what you mention now in the past week. i think giving you a week to say something is reasonable. if you have to fix internals to make then build or work on windows - i don't see that as a blocker to an alpha release. ok - then it doesn't work on windows. are you planning on ripping around with core efl api's and breaking them because of windows? are you planing on adding new features and so on that are not already there? if you are - you should have mentioned it. a new feature is not oh - i made threadsafeness work on windows since it was now added to eina. that's not adding a feature. that's fixing a bug. it's an alpha release. it gets to have bugs. in fact it is KNOWN to already have bugs. nothing new. they will get nuked between alpha and beta. maybe there will be more than 1 alpha if the bug list takes long enough to crunch through. thats a week ago. not the smartest thing you ever did forgetting that email was ever sent. :) i've not forgotten it. Btw, the only thing i mention and that can block (imo only) is the thread safe stuff. Which happended very recently. Other things i mentioned are mostly related to windows. And as i said in irc, i was away during one month. No possible commit for me since mid july. Otherwise there would have been a lot of things i would have modified. Did you forgot that ? see above. i asked. nothing listed. being away is entirely orthogonal - and it's even better actually... it means you are unlikely to be in the middle of something :) The way the release is done is just random. I really prefered Gustavo's way: a plan put somewhere in the wiki. At least we were warned long before, with precise dates. totally not random. i've sent 2 mails related to release in the past few weeks. and this is an alpha. if shit is broken - so be it. it's broken. if we made a mistake - then we made one. we have been TALKING of a release for months. if we did it gustavo's way we would have had a totally arbitray timeline that no one followed and had no bearing on reality that may have made several efl libs 1.0, 1.1, 1.2, 2.0, 2.5, 3.0 etc. by now. ask cedric about having to now maintain a whole bunch of legacy code in eet since it was released as 1.0 (which i argued against repeatedly and did only to prove a point to gustavo that it's simply not ready yet - and now we have eet 1.3.x depending on eina 0.x which isnt even a stable api or release. hooray! need i say more.). my way has meant a slow and steady move with todo lists being worked on and ticked off and things getting to the well nothing left to do stage which is what i was checking in on as i thought we were about there. i asked - you did not disagree or provide any information. what do you expect me to do? i did the right thing. i asked. you replied. you gave no list of things you are working on that need to be done by 1.0.0 alpha Vincent * no new features etc. * ONLY documentation fixes * ONLY bug fixes that are tested and work * ONLY formatting and documentation fixes * ONLY build fixes if they don't build or install things in the right place after freeze i'll be going through and removing sonames from libraries. they will also up their so version to 1.0.0. as this is an alpha it is intended to become 1.0.0 directly and the intent between now and 1.0.0 proper is simply fixing bugs (internally) - stuff that doesn't work, has a FIXME to finish it off, etc. - ONLY api breaks we can do from this freeze on until a 1.0.0 proper are absolute emergency ones for when something was really overlooked and we have very little choice. other than that we are on api and abi stability hiatus until full efl 1.0.0 so - you have until midnight saturday GMT (0:00 sunday morning) to finish off your4 last second stuff. if you don't get it in by then... too late. it likely already is too late now anyway. but this is your last hail-mary pass. if you are at a loss for
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010 17:27:59 +0300 Tom Hacohen t...@stosb.com said: Hey raster, What's the scheduled date of the end of the freeze? ummm probably no longer than 24-48hrs or so from freeze start - less if i can get stuff done and cleaned up nicely. of course shit can happen :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, Aug 14, 2010 at 4:35 PM, Carsten Haitzler ras...@rasterman.comwrote: ummm probably no longer than 24-48hrs or so from freeze start - less if i can get stuff done and cleaned up nicely. of course shit can happen :) Oh, that's barely a freeze :P -- Tom. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010 18:00:28 +0300 Tom Hacohen t...@stosb.com wrote: On Sat, Aug 14, 2010 at 4:35 PM, Carsten Haitzler ras...@rasterman.comwrote: ummm probably no longer than 24-48hrs or so from freeze start - less if i can get stuff done and cleaned up nicely. of course shit can happen :) Oh, that's barely a freeze :P Can we call it a code chill ? -- Mike Blumenkrantz Zentific: Our boolean values are huge. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, Aug 14, 2010 at 3:35 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 14 Aug 2010 17:27:59 +0300 Tom Hacohen t...@stosb.com said: Hey raster, What's the scheduled date of the end of the freeze? ummm probably no longer than 24-48hrs or so from freeze start - less if i can get stuff done and cleaned up nicely. of course shit can happen :) Ok, this is really short. I am almost done with new edje file format, but everything is not yet in and I would have liked some time to be sure that the format is really fine. I am focusing on that right now. But that's not the only thing I dont consider ready for alpha. Eina received a lot of path recently, and I didn't have time to review it (and I don't know who wrote eina_strbuf.c but it lack a proper test and coverage is 0). Same goes for Ecore, received too much stuff recently. I would really like to see this week as a freeze week. I mean, time for API review, time to fix a bunch of bugs and see if we are really ok to support that API/file format for a long time. Maybe I am misunderstanding, but when we say alpha, that means we are going to support the API we are exposing today for a long time. So what do you think about having a longer period of freeze then ? -- Cedric BAIL -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_theme doxygen fix.
On Wed, Aug 11, 2010 at 11:39 AM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Dear all, this is Daniel Juyung Seo. I found one doxygen mistyping in elm_theme.c elm_theme_extension_add() uses eina_list_append() not eina_list_prepend(). So it should be changed to 'Appends'. In svn. thanks. Lucas De Marchi -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, Aug 14, 2010 at 6:17 PM, Cedric BAIL cedric.b...@free.fr wrote: I would really like to see this week as a freeze week. I mean, time for API review, time to fix a bunch of bugs and see if we are really ok to support that API/file format for a long time. Maybe I am misunderstanding, but when we say alpha, that means we are going to support the API we are exposing today for a long time. So what do you think about having a longer period of freeze then ? Sounds reasonable. +1 from me. -- Tom. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010, Carsten Haitzler (The Rasterman) wrote: On Sat, 14 Aug 2010 16:16:45 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: why did it need a date? i asked what is left blocking? you stayed mum about it for a week. i didn't ask for your own task schedule and dates - simply what is there left to do? - no mention of what you mention now in the past week. i think giving you a week to say something is reasonable. if you have to fix internals to make then build or work on windows - i don't see that as a blocker to an alpha release. ok - then it doesn't work on windows. are you planning on ripping around with core efl api's and breaking them because of windows? are you planing on adding new features and so on that are not already there? if you are - you should have mentioned it. a new feature is not oh - i made threadsafeness work on windows since it was now added to eina. that's not adding a feature. that's fixing a bug. it's an alpha release. it gets to have bugs. in fact it is KNOWN to already have bugs. nothing new. they will get nuked between alpha and beta. maybe there will be more than 1 alpha if the bug list takes long enough to crunch through. thats a week ago. not the smartest thing you ever did forgetting that email was ever sent. :) i've not forgotten it. Btw, the only thing i mention and that can block (imo only) is the thread safe stuff. Which happended very recently. Other things i mentioned are mostly related to windows. And as i said in irc, i was away during one month. No possible commit for me since mid july. Otherwise there would have been a lot of things i would have modified. Did you forgot that ? see above. i asked. nothing listed. being away is entirely orthogonal - and it's even better actually... it means you are unlikely to be in the middle of something :) The way the release is done is just random. I really prefered Gustavo's way: a plan put somewhere in the wiki. At least we were warned long before, with precise dates. totally not random. i've sent 2 mails related to release in the past few weeks. and this is an alpha. if shit is broken - so be it. it's broken. if we made a mistake - then we made one. we have been TALKING of a release for months. if we did it gustavo's way we would have had a totally arbitray timeline that no one followed and had no bearing on reality that may have made several efl libs 1.0, 1.1, 1.2, 2.0, 2.5, 3.0 etc. by now. ask cedric about having to now maintain a whole bunch of legacy code in eet since it was released as 1.0 (which i argued against repeatedly and did only to prove a point to gustavo that it's simply not ready yet - and now we have eet 1.3.x depending on eina 0.x which isnt even a stable api or release. hooray! need i say more.). my way has meant a slow and steady move with todo lists being worked on and ticked off and things getting to the well nothing left to do stage which is what i was checking in on as i thought we were about there. i asked - you did not disagree or provide any information. what do you expect me to do? i did the right thing. i asked. you replied. you gave no list of things you are working on that need to be done by 1.0.0 alpha You're always right, of course... I'm fed up, do what you want, as always. Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] evas BMP loader - fix for 32-bit BMP files saved by GIMP
On Sat, Aug 14, 2010 at 9:11 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 14 Aug 2010 21:06:33 +0800 Brian Wang brian.wang.0...@gmail.com said: On Sat, Aug 14, 2010 at 6:24 PM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 11 Aug 2010 10:27:58 +0800 Brian Wang brian.wang.0...@gmail.com said: Hello raster, I stole some time and made an app for showing bitmaps in bmpsuite.zip. Please see the PNG screenshot disguised in txt as attached. All bitmaps are shown (properly, i think). gqview seems a bit weaker than evas. :-) And yes, 32-bit bmp is a format i care a lot of since the loading is a lot faster. :-) On a platform with weak computing power, i have to save bits and pieces here and there. If there's no problem, please check my patch and correct it when you see fit. hmm well the text file attached corrupted - cant see it. but... i also created a mini image viewer too for this purpose. as such your patch will break transparent bmp's (100%) which is really an incorrect thing. if you can find a way to make it not incorrect - no problems. i really don't like the fix because of its nature. Well, that's what GIMP does. I guess it's a workaround and it'll be 99.99% accurate since 100% transparent BMPs aren't exactly popular. 32-bit BMPs aren't popular either. If my patch is not ok for the upstream, I'll just keep it private. I'm perfectly ok with it. sure - though it's once thing being a paining program (gimp) and getting a bmp load of a totally blank bmp wrong and being a generic library that loads images generically for any purpose. gimp can afford to get it wrong without much hassle - it's a bigger problem for evas to get it wrong as the intended usage is much less clearly defined :) OK. That's a sane argument. Please note that Evas does not load 32-bit BMP with non-opaque pixels created by GIMP properly. I guess GIMP just creates those based on a standard with added flavors. By the way, SDL_image loads those just fine (Evas also beats it on compatibilities too). If I ever have time and come up with a patch that does not break 100% transparent 32-bit BMPs, I'll let the list know. :-) but what i'm more concerned about is.. why are bmp's faster to load? really? seriously? you've tested? vs what other formats? i really didnt make any effort to make the bmp loader fast. i just implemented it to follow the standards (that's why u find evas's bmp loader beat gqview by a large mile as the gtk one is enferior with standards support than evas's). when i do something i tend to like to do it right. now - you'll need to convince me much more that your hack is a valid patch as it really doesnt follow a standard. what is more of interest to me is the bmp loading being faster than... something else? what is that something else? I haven't benchmarked BMP vs PNG loading speed with Evas. The 'BMP is faster to load' argument is based on various icon-loading (small 32x32 icons) tests I performed on my prior project (ARM920T device @400MHz), which uses SDL/SDL_Image. I think Evas is smarter with images but I just assume loading/render of raw data (BMP) would be faster than with compressed PNG files. well that depends. you pay a decompress cost - cpu time, but uncompressed (raw) images you pay an IO cost. so which is worse. load 50kb from flash and spend cpu time decompressing... or load 200kb from flash and spend no cpu time decompressing. also with png you can select your compression level and tune things. i suggest you do some actual examining of this with your current target and try png's with various compression levels. you also can use eet to store images (all even in a single file) and then use lossy or lossless compression, as well as zero compression (raw argb). so if performance is an issue - bmp isnt your only option. other formats give you a wider choice. On my device and based on my experiments, raw data I/O beats compressed data I/O + decompression. Of course, it doesn't apply to all platforms with different I/O performance and computing power. Just for the record, I'm not saying BMP offers a _huge_ performance gain. I'll try to find time and play with different formats. and thanks for the eet tip. I'll see if that causes any problem with my icon/UI artist. :-) BR, brian -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
Cedric BAIL wrote: But that's not the only thing I dont consider ready for alpha. Eina received a lot of path recently, and I didn't have time to review it (and I don't know who wrote eina_strbuf.c but it lack a proper test and coverage is 0). Same goes for Ecore, received too much stuff recently. strbuf comes from ecore. There is a eina_test_strbuf.c which had very nice coverage when I added it. Sebastian -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Setting twice the same icon file to an elm_icon object makes it disappear
Hi, i'm simply forwarding the ticket URL, just to be sure that a fix will make its way in time before the 1.0 release. http://trac.enlightenment.org/e/ticket/569 -- daniele_athome -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, Aug 14, 2010 at 6:17 PM, Cedric BAIL cedric.b...@free.fr wrote: But that's not the only thing I dont consider ready for alpha. Eina received a lot of path recently, and I didn't have time to review it (and I don't know who wrote eina_strbuf.c but it lack a proper test and coverage is 0). Same goes for Ecore, received too much stuff recently. Strbuf shares a lot of code with ustrbuf that's why they have a shared source file, eina_strbuf_template_c.ihttp://svn.enlightenment.org/svn/e/trunk/eina/src/lib/eina_strbuf_template_c.i . So although strbuf has 0 coverage, it's just because there are a couple of functions not checked, but not all. Generally, I think the coverage checking does not like stuff like #define FUNC_NAME function_name int FUNC_NAME(int x); (when you set different FUNC_NAME's in different places). -- Tom. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ecore's poll file manager
Hi all,
attached is a small bugfix for ecore. If the to-be-monitored path
doesn't exist, the poll monitor currently tries to remove an item from a
list which was never hooked up.
Joerg
$NetBSD$
--- src/lib/ecore_file/ecore_file_monitor_poll.c.orig 2010-08-14
16:48:51.0 +
+++ src/lib/ecore_file/ecore_file_monitor_poll.c
@@ -95,6 +95,8 @@ ecore_file_monitor_poll_add(const char *
em-data = data;
ECORE_FILE_MONITOR_POLL(em)-mtime = ecore_file_mod_time(em-path);
+ _monitors =
ECORE_FILE_MONITOR(eina_inlist_append(EINA_INLIST_GET(_monitors),
EINA_INLIST_GET(em)));
+
if (ecore_file_exists(em-path))
{
if (ecore_file_is_dir(em-path))
@@ -130,8 +132,6 @@ ecore_file_monitor_poll_add(const char *
return NULL;
}
- _monitors =
ECORE_FILE_MONITOR(eina_inlist_append(EINA_INLIST_GET(_monitors),
EINA_INLIST_GET(em)));
-
return em;
}
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Insecure SVG loader test
hi all, in src/bin/e_main.c there is this wonderful gem _e_main_test_svg_loader. Writting a hard-coded XML file to a known location is just asking for trouble. It basically means that anyone with write access to /tmp can make the E17 user overwrite a file with permissions of the user. It also creates race conditions for multiple users. Any reason why this piece of code is needed at all? While looking at seemingly redundant code: why is e_fm_mime_icon_get not using efreet? Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sat, 14 Aug 2010 23:13 +0200, Joerg Sonnenberger wrote : hi all, in src/bin/e_main.c there is this wonderful gem _e_main_test_svg_loader. Writting a hard-coded XML file to a known location is just asking for trouble. It basically means that anyone with write access to /tmp can make the E17 user overwrite a file with permissions of the user. It also creates race conditions for multiple users. Thanks for sending this. I think I mentionned it on IRC at one point, and then forgot about it. Any reason why this piece of code is needed at all? That's a little bit complicated: - The freedesktop.org spec says that SVG icons lookup is optional, but if it is supported, then the lookup order is png - svg - xpm - If efreet returns an SVG icon when SVG rendering is not compiled in evas, then you get no icon where an xpm icon (which could have been rendered correctly) might have existed. - Since there is no way to ask evas if SVG support is available (which I think is a mistake), you need to do some kind of runtime detection. - Right now, the only practical way to do that is using some voodoo: create a dummy file and try to load it. To sum it up: it's here because such kind of tests are the only way to check whether Evas supports a particular format. Or at least, so were they when the patch got commited. Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sat, Aug 14, 2010 at 11:35:13PM +0200, Albin Tonnerre wrote: - If efreet returns an SVG icon when SVG rendering is not compiled in evas, then you get no icon where an xpm icon (which could have been rendered correctly) might have existed. OK - Since there is no way to ask evas if SVG support is available (which I think is a mistake), you need to do some kind of runtime detection. Yes, that's bad. - Right now, the only practical way to do that is using some voodoo: create a dummy file and try to load it. Why not use install the dummy file to a known location and try loading it that way? share/enlightenment/data/icons/dummy.svg or so. Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sat, 14 Aug 2010 23:46 +0200, Joerg Sonnenberger wrote : On Sat, Aug 14, 2010 at 11:35:13PM +0200, Albin Tonnerre wrote: - If efreet returns an SVG icon when SVG rendering is not compiled in evas, then you get no icon where an xpm icon (which could have been rendered correctly) might have existed. OK - Since there is no way to ask evas if SVG support is available (which I think is a mistake), you need to do some kind of runtime detection. Yes, that's bad. - Right now, the only practical way to do that is using some voodoo: create a dummy file and try to load it. Why not use install the dummy file to a known location and try loading it that way? share/enlightenment/data/icons/dummy.svg or so. I can't recall, and like I said I'd much rather have Evas being able to expose the information. But if it's not going to happen, then the file should either be shipped with e17 or created in a more secure manner (I'd prefer that, but that's a matter of personal taste). Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] efreet and icon loading
Hi all,
attached patch fixes two issues:
(1) If using a non-default prefix, share/pixmaps should be checked
before the hard-coded /usr/share/pixmaps fallback. This basically
restores symmetry with the other cases like share/icons.
(2) Do a fallback lookup if the theme is not valid or faked. This can
happen if only hicolor is installed and e17 decides to use Tango.
Before, e.g. gimp's icon wasn't picked up because the short cut was too
early.
Joerg
$NetBSD$
--- efreet_icon.c.orig 2010-05-18 06:45:13.0 +
+++ efreet_icon.c
@@ -549,14 +549,16 @@ efreet_icon_find_helper(Efreet_Icon_Them
efreet_icon_theme_cache_check(theme);
-/* go no further if this theme is fake */
-if (theme-fake || !theme-valid) return NULL;
/* limit recursion in finding themes and inherited themes to 256 levels */
if (recurse 256) return NULL;
recurse++;
-value = efreet_icon_lookup_icon(theme, icon, size);
+/* go no further if this theme is fake */
+if (theme-fake || !theme-valid)
+ value = NULL;
+else
+ value = efreet_icon_lookup_icon(theme, icon, size);
/* we didin't find the image check the inherited themes */
if (!value || (value == NON_EXISTING))
@@ -861,6 +863,17 @@ efreet_icon_fallback_icon(const char *ic
}
}
+EINA_LIST_FOREACH(xdg_dirs, l, dir)
+{
+snprintf(path, PATH_MAX, %s/pixmaps, dir);
+icon = efreet_icon_fallback_dir_scan(path, icon_name);
+if (icon)
+{
+efreet_icon_cache_add(efreet_icon_find_theme_check(NULL),
icon_name, 0, icon);
+return icon;
+}
+}
+
icon = efreet_icon_fallback_dir_scan(/usr/share/pixmaps, icon_name);
}
@@ -1260,6 +1273,12 @@ efreet_icon_theme_dir_scan_all(const cha
efreet_icon_theme_dir_scan(path, theme_name);
}
+EINA_LIST_FOREACH(xdg_dirs, l, dir)
+{
+snprintf(path, sizeof(path), %s/pixmaps, dir);
+efreet_icon_theme_dir_scan(path, theme_name);
+}
+
efreet_icon_theme_dir_scan(/usr/share/pixmaps, theme_name);
}
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] evas BMP loader - fix for 32-bit BMP files saved by GIMP
On Sun, 15 Aug 2010 01:19:32 +0800 Brian Wang brian.wang.0...@gmail.com said: sure - though it's once thing being a paining program (gimp) and getting a bmp load of a totally blank bmp wrong and being a generic library that loads images generically for any purpose. gimp can afford to get it wrong without much hassle - it's a bigger problem for evas to get it wrong as the intended usage is much less clearly defined :) OK. That's a sane argument. Please note that Evas does not load 32-bit BMP with non-opaque pixels created by GIMP properly. I guess GIMP just creates those based on a standard with added flavors. By the way, SDL_image loads those just fine (Evas also beats it on compatibilities too). If I ever have time and come up with a patch that does not break 100% transparent 32-bit BMPs, I'll let the list know. :-) there must be some more correct way - my guess is gimp actually creates bmp's incorrectly (right now) to get an alpha channel in. that's my guess. or someone somewhere broke a standard and everyone has had to cope very since. but there has to be a sane way to do this without having this all blank bmp becomes not all-blank problem. but what i'm more concerned about is.. why are bmp's faster to load? really? seriously? you've tested? vs what other formats? i really didnt make any effort to make the bmp loader fast. i just implemented it to follow the standards (that's why u find evas's bmp loader beat gqview by a large mile as the gtk one is enferior with standards support than evas's). when i do something i tend to like to do it right. now - you'll need to convince me much more that your hack is a valid patch as it really doesnt follow a standard. what is more of interest to me is the bmp loading being faster than... something else? what is that something else? I haven't benchmarked BMP vs PNG loading speed with Evas. The 'BMP is faster to load' argument is based on various icon-loading (small 32x32 icons) tests I performed on my prior project (ARM920T device @400MHz), which uses SDL/SDL_Image. I think Evas is smarter with images but I just assume loading/render of raw data (BMP) would be faster than with compressed PNG files. well that depends. you pay a decompress cost - cpu time, but uncompressed (raw) images you pay an IO cost. so which is worse. load 50kb from flash and spend cpu time decompressing... or load 200kb from flash and spend no cpu time decompressing. also with png you can select your compression level and tune things. i suggest you do some actual examining of this with your current target and try png's with various compression levels. you also can use eet to store images (all even in a single file) and then use lossy or lossless compression, as well as zero compression (raw argb). so if performance is an issue - bmp isnt your only option. other formats give you a wider choice. On my device and based on my experiments, raw data I/O beats compressed data I/O + decompression. Of course, it doesn't apply to all platforms with different I/O performance and computing power. Just for the record, I'm not saying BMP offers a _huge_ performance gain. I'll try to find time and play with different formats. and thanks for the eet tip. I'll see if that causes any problem with my icon/UI artist. :-) it's probably a very good idea to have a little test suite for yourself here. if it really matters to you - have a bunch of formats with a bunch of images that are typical of your usage (small, medium, large, simple, complex etc. content) and then try a range of formats and options within those formats and test time to load :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, 14 Aug 2010 17:17:51 +0200 Cedric BAIL cedric.b...@free.fr said: On Sat, Aug 14, 2010 at 3:35 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 14 Aug 2010 17:27:59 +0300 Tom Hacohen t...@stosb.com said: Hey raster, What's the scheduled date of the end of the freeze? ummm probably no longer than 24-48hrs or so from freeze start - less if i can get stuff done and cleaned up nicely. of course shit can happen :) Ok, this is really short. I am almost done with new edje file format, but everything is not yet in and I would have liked some time to be sure that the format is really fine. I am focusing on that right now. But that's not the only thing I dont consider ready for alpha. Eina received a lot of path recently, and I didn't have time to review it (and I don't know who wrote eina_strbuf.c but it lack a proper test and coverage is 0). Same goes for Ecore, received too much stuff recently. I would really like to see this week as a freeze week. I mean, time for API review, time to fix a bunch of bugs and see if we are really ok to support that API/file format for a long time. Maybe I am misunderstanding, but when we say alpha, that means we are going to support the API we are exposing today for a long time. So what do you think about having a longer period of freeze then ? well i'm almost willing to say all the eina threadsafe stuff should probably be removed for efl 1.0.0 due to its immaturity. it's not small nad this will piss stu off - but most of efl has had years of godo testing even with no test suties via things like e, elementary, freebox, etc. etc. so its rather solid. small added bits here and there are probably ok - like adding an accessor or a trivial function. some things have had api for a long time and are missing internal hooks (evas engine stuff in some cases) but the api is right (i'm pretty sure) and designed for the right reasons, just the internal support is not there yet. alpha is expected to be buggy - so fixing bugs is not something we should care about freeze-wise. this freeze was simply so we can fix up code formatting, readme's, installed files (so versions, sonames etc.) without having to wrestle with a moving target. i am not averse to having an alpha2, alpha3 etc. etc. so eina threadsafe stuff - very very very immature. not what i'd call having stood the test of time by any stretch. regardless if there is a test suite. api's only stand or fall by the test of time and real world usage. you get a bonus if the api designer has done it maany times before, but still is not totally there even then. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
Quoting Albin Tonnerre albin.tonne...@gmail.com: On Sat, 14 Aug 2010 23:46 +0200, Joerg Sonnenberger wrote : On Sat, Aug 14, 2010 at 11:35:13PM +0200, Albin Tonnerre wrote: - If efreet returns an SVG icon when SVG rendering is not compiled in evas, then you get no icon where an xpm icon (which could have been rendered correctly) might have existed. OK - Since there is no way to ask evas if SVG support is available (which I think is a mistake), you need to do some kind of runtime detection. Yes, that's bad. - Right now, the only practical way to do that is using some voodoo: create a dummy file and try to load it. Why not use install the dummy file to a known location and try loading it that way? share/enlightenment/data/icons/dummy.svg or so. I can't recall, and like I said I'd much rather have Evas being able to expose the information. But if it's not going to happen, then the file should either be shipped with e17 or created in a more secure manner (I'd prefer that, but that's a matter of personal taste). you can test that only at runtime and not at configure time, as someone can add the svg loader (as a shared lib) after an installation of evas. So it can only be after testing a svg file, I think. Vincent This message was sent using IMP, the Internet Messaging Program. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
Quoting Carsten Haitzler (The Rasterman) ras...@rasterman.com: On Sat, 14 Aug 2010 18:33:35 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: thought we were about there. i asked - you did not disagree or provide any information. what do you expect me to do? i did the right thing. i asked. you replied. you gave no list of things you are working on that need to be done by 1.0.0 alpha You're always right, of course... I'm fed up, do what you want, as always. well if this is how you see it - then not much i can do. there is nothing i can do in such a situation. you will be upset no matter what is done unless you yourself determine everything, because you didn't share your objectives with everyone else. you're one of the few people who are actually reliable and trustworthy. if you don't say you have something to do, i believe it. i'm not doing what i want to do just because thats how i want it. i engaged the developers - both on email and irc - our primary communication mechanisms - you included. you didn't miss the emails. you have a whole alpha phase to do things during (as long as they are not breaking api). this alpha won't be perfect. far from it. but i'm sad to see you upset at me, yet there is nothing i could have done to prevent it as the source of it all is yourself and your actions, so it's something you have to come to terms with. sorry. as i said - i trust your word. you've earned that over the many years. :( Yes, I'm upset, because, now, the development is a mess. You, the lead dev, announce a release (which is great), but you accept that, after that announce, plenty of people commit plenty of stuff, with maybe a broken API, not respecting the implicit naming rule (like in eet, for example... But it's too late now for this lib). Cedric finished his changes on edje yesterday (btw, is it really finished, tested, etc... ?). I would have preferred that kind of announce: Since 2 weeks, the points i mentioned (edje format, etc...) are now in svn. Do you guys think that it's mature ? One week for testing and cleaning could be sufficient. I plan a release one week Or something like that. And not annoucing the alpha release the day after the last commit of cedric on the new edje format. I would have agreed without any problem with that kind of announce. We wait for several years for a release. One week to check the API and *potential big* problems after such a big change like the new edje format is important. That's my point of view Vincent This message was sent using IMP, the Internet Messaging Program. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
