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
Re: [E-devel] Release schedule
On Thu, Feb 26, 2009 at 12:22 AM, The Rasterman Carsten Haitzler wrote: > On Wed, 25 Feb 2009 14:41:41 +0100 Cedric BAIL said: > >> On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri >> wrote: >> > On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL wrote: >> >> On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri >> >> wrote: >> >>> On Wed, Jan 28, 2009 at 9:04 PM, Toma 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] Release schedule
On Wed, 25 Feb 2009 14:41:41 +0100 Cedric BAIL said: > On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri > wrote: > > On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL wrote: > >> On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri > >> wrote: > >>> On Wed, Jan 28, 2009 at 9:04 PM, Toma 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] 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] Submit this EWL bug in tracker?
Terseus schrieb: > I have news about the notebook bug. > > The best would be a small test case to reproduce the bug, in most > cases this shouldn't be too hard to write and is for you easier, > then for us to figure out what you are doing in detail. > > > A great idea indeed, while doing the test software I notice that when > I trigger the callback functions of create and destroy pages from > buttons (Ewl_Button) it DOES work perfectly even without EWL warnings, > but when I trigger them from menu items (Ewl_Menu_Item) both the bug > and the warnings reappears. Yeah, reducing a problem to the minimum of needed function calls, often shows very clearly where the problem is located, no matter if it is in your or ewl's code. > > I'm now thinking about this can be a bug in my code, but it's strange > because I use the same callbacks in both the menu items and buttons. > > I'm doing a complete showcase test of the bug creating and destroying > pages in a variety of ways but will need time, I'm very busy right now > with my work and another project. Sure, take the time you need. 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
[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] Release schedule
On Wed, Feb 25, 2009 at 1:47 PM, Cedric BAIL wrote: > On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri > wrote: >> On Wed, Jan 28, 2009 at 9:04 PM, Toma 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
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri wrote: > On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL wrote: >> On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri >> wrote: >>> On Wed, Jan 28, 2009 at 9:04 PM, Toma 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 9:47 AM, Cedric BAIL wrote: > On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri > wrote: >> On Wed, Jan 28, 2009 at 9:04 PM, Toma 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:01 PM, Thomas Gstädtner wrote: > On Wed, Feb 25, 2009 at 1:47 PM, Cedric BAIL wrote: >> On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri >> wrote: >>> On Wed, Jan 28, 2009 at 9:04 PM, Toma 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 Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri wrote: > On Wed, Jan 28, 2009 at 9:04 PM, Toma 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 Tue, 24 Feb 2009, Gustavo Sverzut Barbieri wrote: > On Wed, Jan 28, 2009 at 9:04 PM, Toma 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. > > I'd like some help to finish the list, mostly on the usability front. > You don't need to really know how to code, I can do code, but I need > you to go review menus and dialogs, specially layout and phrasing, to > make them simpler and shorter. Please open new wiki pages and attach > mockups there, describe your ideas, if we find them reasonable we'll > do the code. Please see these items: > > Reorganize, Layout and Visual Changes: > * fix many labels and widgets to be shorter/simpler (save space) > and more obvious. > * clean up as many menus as possible (labels, ordering, layout). > simplify and re-organise. > > 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 :-) I plan to remove some items in evas section (mainly the engines). I'll also take a look at the llvm reports (boring stuff...) Vincent -- 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
