Re: [E-devel] Release schedule
On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). - remove last user of evas_hash and evas_list (they did appear between the start of the move and the actual commit) - remove evas_hash and evas_list from Evas. - remove the last standing ecore_list (some use in e modules and ewl mainly) - move to eina module infrastructure for evas, ecore and e. - move to eina rectangle in evas. - move to eina error for displaying error message. - remove ecore magic and use eina magic. That's a small list, representing a little amount of work. But you can just run grep on the svn and start committing small change as most of this item will not impact external API (So I will not be the only one breaking E svn) As always, have fun ! -- Cedric BAIL -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 2:01 PM, Thomas Gstädtner tho...@gstaedtner.net wrote: On Wed, Feb 25, 2009 at 1:47 PM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). - remove last user of evas_hash and evas_list (they did appear between the start of the move and the actual commit) - remove evas_hash and evas_list from Evas. - remove the last standing ecore_list (some use in e modules and ewl mainly) - move to eina module infrastructure for evas, ecore and e. - move to eina rectangle in evas. - move to eina error for displaying error message. - remove ecore magic and use eina magic. Should ecore_list stay in and only the doubly linked lists replaced by eina? If ecore_lists will removed, too, it is not only used in e17, but also by some ecore internals, i.e. ecore_path_group. Already gone :-) -- Cedric BAIL -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). ... I'd say we should inspect places where lists and specially list *copies* are returned and use eina_iterator or eina_accessor instead. In many places we dup the list (1 walk), then use it (+1 walk), then free it (+1 walk), so 3 walk for a simple task. If we used the iterator stuff we could alloc a small amount of memory and do the same thing, just more clean, safer and faster. Comes to mind evas_render_method_list() and similar. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). ... I'd say we should inspect places where lists and specially list *copies* are returned and use eina_iterator or eina_accessor instead. In many places we dup the list (1 walk), then use it (+1 walk), then free it (+1 walk), so 3 walk for a simple task. If we used the iterator stuff we could alloc a small amount of memory and do the same thing, just more clean, safer and faster. Comes to mind evas_render_method_list() and similar. Yes, returning Eina_Iterator would be a better solution in many place in the EFL API. Could be faster and more memory efficient for many case, and it will explicitely say that a the content of a list should not be destroyed/modified by the caller. -- Cedric BAIL -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 1:47 PM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). - remove last user of evas_hash and evas_list (they did appear between the start of the move and the actual commit) - remove evas_hash and evas_list from Evas. - remove the last standing ecore_list (some use in e modules and ewl mainly) - move to eina module infrastructure for evas, ecore and e. - move to eina rectangle in evas. - move to eina error for displaying error message. - remove ecore magic and use eina magic. Should ecore_list stay in and only the doubly linked lists replaced by eina? If ecore_lists will removed, too, it is not only used in e17, but also by some ecore internals, i.e. ecore_path_group. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore and Enlightenment compilation
Hello all,
I'm new to this mailing-list, so sorry if it is not the right place to speak
about my little compilation failure. Since the last revision (39219) of the
Ecore and Enlightenment ebuilds (I'm on gentoo), it seems that there is some
bugs into ecore_evas_fb.c, line 100 :
static void
_ecore_evas_fb_gain(void *data __UNUSED__)
{
Ecore_List2 *l;
Eina_List *l; *-- duplication declaration ???*
Ecore_Fb_Input_Device *dev;
for (l = (Ecore_List2 *)ecore_evases; l; l = l-next)
{
Ecore_Evas *ee;
ee = (Ecore_Evas *)l;
ee-visible = 1;
if ((ee-rotation == 90) || (ee-rotation == 270))
evas_damage_rectangle_add(ee-evas, 0, 0, ee-h, ee-w);
else
evas_damage_rectangle_add(ee-evas, 0, 0, ee-w, ee-h);
}
if (ecore_evas_input_devices)
{
EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) *-- where comes
the ll variable ???*
ecore_fb_input_device_listen(dev, 1);
}
}
and at ligne 524 :
EINA_LIST_FOREACH(ecore_evas_input_devices, l, dev)
ecore_fb_input_device_axis_size_set(dev, ee-wn ee-h); *-- seems
that there is no variable named 'wn'*
}
The other problem seems to be into the Ecore_File.h at line 87 :
EAPI Ecore_List *ecore_file_ls (const char *dir); *-- should'nt
be Eina_List instead of Ecore_List ???*
Thanks for your response !
Best regards,
Cedric Tabin
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Submit this EWL bug in tracker?
Terseus schrieb: Sorry, I forgot to mention one thing, when I create a page in a notebook widget and destroy it, if I try now to destroy a page with the notebook empty the function ewl_notebook_visible_page_get still give me a not NULL widget (the same offset of the previously destroyed widget) which pass the if( !widget ) check, I have add a check but is redundant; now my code look like this: Oh, indeed it looks like the current (saved) page isn't set to NULL or anything else. if the page is removed. That's not good. I'll hopefully take a look on it tomorrow. if( !page_box ) return; if( !EWL_WIDGET_IS( pagebox ) ) return; The first is necessary to avoid an EWL warning thant happen when EWL_WIDGET_IS is called with a NULL pointer, the second for the ewl_notebook_visible_page_get behavior, is this intentioned or a bug? Right, EWL_WIDGET_IS() warns on NULL arguments. That's intentionally. But a test on EWL_WIDGET_IS() is always a sign of a bug, because all the EWL_*_IS() macros only work with widgets, if the give pointer is not a widget the result of the function is undefined. It may even segfault. So most probably, what you get from ewl_notebook_visible_page_get() is simply wrong. Peter -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, 25 Feb 2009 14:41:41 +0100 Cedric BAIL cedric.b...@free.fr said: On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). ... I'd say we should inspect places where lists and specially list *copies* are returned and use eina_iterator or eina_accessor instead. In many places we dup the list (1 walk), then use it (+1 walk), then free it (+1 walk), so 3 walk for a simple task. If we used the iterator stuff we could alloc a small amount of memory and do the same thing, just more clean, safer and faster. Comes to mind evas_render_method_list() and similar. Yes, returning Eina_Iterator would be a better solution in many place in the EFL API. Could be faster and more memory efficient for many case, and it will explicitely say that a the content of a list should not be destroyed/modified by the caller. beware of being too gung-ho. some of htese (like evas_render_method_list()) are called so rarely you likely just make the api harder to use for no real gain. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Thu, Feb 26, 2009 at 12:22 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: On Wed, 25 Feb 2009 14:41:41 +0100 Cedric BAIL cedric.b...@free.fr said: On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). ... I'd say we should inspect places where lists and specially list *copies* are returned and use eina_iterator or eina_accessor instead. In many places we dup the list (1 walk), then use it (+1 walk), then free it (+1 walk), so 3 walk for a simple task. If we used the iterator stuff we could alloc a small amount of memory and do the same thing, just more clean, safer and faster. Comes to mind evas_render_method_list() and similar. Yes, returning Eina_Iterator would be a better solution in many place in the EFL API. Could be faster and more memory efficient for many case, and it will explicitely say that a the content of a list should not be destroyed/modified by the caller. beware of being too gung-ho. some of htese (like evas_render_method_list()) are called so rarely you likely just make the api harder to use for no real gain. :) not harder, easier! Just get used to iterators and accessors, you'll love them. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore and Enlightenment compilation
On Wed, Feb 25, 2009 at 11:17:17PM +0100, Cédric Tabin wrote: Hello all, I'm new to this mailing-list, so sorry if it is not the right place to speak about my little compilation failure. You came to the right place :-) Since the last revision (39219) of the Ecore and Enlightenment ebuilds (I'm on gentoo), it seems that there is some bugs into ecore_evas_fb.c, line 100 : These issues has just been fixed in svn. Please update and give it another go. Regards Lars Munch -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
