From: Veli O. S. <vel...@gm...> - 2009-01-29 12:07:11
|
On Thu, Jan 29, 2009 at 2:04 AM, Toma <tom...@gm...> wrote: > > I propose February 14th. Its close, realistic, and might dull the > loneliness of Valentines Day. :) > > -Toma. > > > Ahaha, indeed. -- Veli Sungutay http://www.lyciasoft.com |
From: Toma <tom...@gm...> - 2009-01-29 14:01:26
|
2009/1/29 sda <dmi...@gm...>: > On 09:04 Thu 29 Jan , Toma wrote: > >> As the top of the page says, we need to finalize the list of things >> TODO. > > hi guys, > > i'm not the dev so beg your pardon if things below are "out of scope". > > 1) after the review of a mentioned page > (http://trac.enlightenment.org/e/wiki/Release) > i decide to fill 'trac' with some more 'tickets'/(requests) instead of > the page modification. assume that it's your (and not mine) decision to > set a milestone to the Release. > > 2) there're no 'magic' word we're all aware about (no doubt that it ... > you know...). here it is (in capital letters): > == "SYSTRAY" == > suppose that clear definition of our POV to this case is required. it's > o'k not to make one and explain why. but Release of a Desktop Shell > without a tray will attract less Users i guess. yes, Wiki FAQ advise to > use 'trayer', 'stalonetray', etc., but references to the various > discussions are unable to state the case clear. > There was a systray mention on there a while ago... maybe it was a different TODO list. Added in modules-extra for now. > 3) annoying question related to the "color and font config modules". as > it was mentioned by Raster: > >>thats what i meant - just wouldn't compile the color and font config modules. >>they they wont appear anywhere. code will be there - just not being compiled or >>used until its fixed. > > ok. but does it mean that all themes/(.edj files) which use custom fonts > and/or "color_class:"-es will require maintenance? if "Yes!", then > suppose that the info should be spread all over the community or only new > default theme will remain usable (it's a nice option, but some may > prefer other variants). > I think scraping the modules to config it would be good, but leave the support for it via enlightenment_remote would be good as well. If anyone was keen, they could revamp it and reintroduce into a major release eg, E17.1. That way, we dont need to alter themes, and if you really want, just include a brief howto in the theme about. Kind of like what i did with Cerium. > 4) another "chewing gum" - "Should add lua support? (optional)" Just > make a decision and say it. No/Yes - doesn't matter much (though the > amount of maintenance if "Yes" will be sufficient). it's a pity that > both VM's ('embryo' and 'lua') can't exist together. > More of a pending decision. Someone was working on an alternate environment with LUA working. Results of that work are yet to be debated and trialed I guess? My personal > 5) last couple of days i'm using 'Ecomorph' and it's much more stable > then "bling" module. suppose that "bling" should be improved (in terms > of stability) or explicitly marked as 'unstable'. yes, FAQ tells that > E17 doesn't work with composite, but it's an easy task for "bling" now > to create a nice segfault of E17 :). > > offtop> http://en.opensuse.org/Ecomorph Only thing stopping ecomorph from being an official module is that it needs drastic changes to the main tree, IIRC. Someone feel free to correct me on that as I havent looked into it. > > 6) as i mentioned in trac ticket #201 the "gap" exist in a window > management between E16/eesh and E17/enlightenment_remote. it could be > nice to eliminate this "mismatch" especially for the experienced Users > of E16. > Like buying a new TV, you need to learn the new remote. :) > 7) the "bridge" between "qt" <-> "edje" && "gtk" <-> "edje" still "under > heavy discussion" suggest to create a couple of themes like existing > "Clearlooks" (it's really nice) to match the major ones used by others. > dunno about "qt" (don't use it here) but it's an easy task to copy a > couple of most popular "gtk+" ones. > With the development of QEdje, a cross to QT/KDE with an E theme might be possible with a bit more persistence. But again, I havent even looked at QEdje and friends since they were released a while back. But in all honesty, we shouldnt worry too much about that. What we SHOULD worry about, is the cross themeing of E with EWL and ETK. It is all very possible, but as a themer yourself, its quite tedious to add the other parts and duplicate and so on. We could of course, investigate making the toolkits (Or toolkit) work with edje parts from an E theme. > > thanks for your kind attention. > regards, > sda > NP. Toma- |
From: sda <dmi...@gm...> - 2009-01-29 15:33:41
|
> There was a systray mention on there a while ago... maybe it was a > different TODO list. Added in modules-extra for now. > ok. thx. > > 3) annoying question related to the "color and font config modules". as > > it was mentioned by Raster: > > > >>thats what i meant - just wouldn't compile the color and font config modules. > >>they they wont appear anywhere. code will be there - just not being compiled or > >>used until its fixed. > > > > ok. but does it mean that all themes/(.edj files) which use custom fonts > > and/or "color_class:"-es will require maintenance? if "Yes!", then > > suppose that the info should be spread all over the community or only new > > default theme will remain usable (it's a nice option, but some may > > prefer other variants). > > > > I think scraping the modules to config it would be good, but leave the > support for it via enlightenment_remote would be good as well. If > anyone was keen, they could revamp it and reintroduce into a major > release eg, E17.1. That way, we dont need to alter themes, and if you > really want, just include a brief howto in the theme about. Kind of > like what i did with Cerium. > please read this thread: http://www.mail-archive.com/enl...@li.../msg20486.html and your response unfortunately doesn't answer the question: "does it mean that all themes/(.edj files) which use custom fonts and/or "color_class:"-es will require maintenance?" the "milestone" left this point as pending (optional). just suppose that clarification is needed. > > 6) as i mentioned in trac ticket #201 the "gap" exist in a window > > management between E16/eesh and E17/enlightenment_remote. it could be > > nice to eliminate this "mismatch" especially for the experienced Users > > of E16. > > > > Like buying a new TV, you need to learn the new remote. :) > the question is not in "learning a new remote" unfortunately. it's more related to the "should we buy this new TV or let's look at another one?" just for fun you can read trac ticket #201 and try to make the same trick with E17. should i prepare the draft of a "Comparison Table" and outline the "mismatches" in general? just assumed that we're all here know a bit about the "roots" and no such things are needed. frankly speaking it doesn't matter will the same functions (like "eesh" has) work with "enlightenment_remote" or via "qdbus" (we're usind dbus now, right?). but i guess that a simple questions like "How many windows/apps are running under E?" should have an answer readable in your terminal app. "eesh" has a clear answer: "eesh window_list". that's it. > What we SHOULD > worry about, is the cross themeing of E with EWL and ETK. It is all > very possible, but as a themer yourself, its quite tedious to add the > other parts and duplicate and so on. We could of course, investigate > making the toolkits (Or toolkit) work with edje parts from an E theme. > nice point. agree with you. but... let's say that IMHO - ETK has a stable API and a bunch of a software which work for my Linux and OpenBSD. EWL is constantly evolving and assume that the "Ephoto" app is the only one in a "pure EWL basket" (plus "Elitaire"?). also "elementary" is coming, right? that's why all my modest .edj files contain E17 + ETK only. and the final question is: - several "unified" themes exist (yep, i created the first one... my fault). can we expect a "unified switcher" to control the look of E17, ETK and EWL from a single location/app? regards, sda |
From: sda <dmi...@gm...> - 2009-01-29 13:32:25
|
On 09:04 Thu 29 Jan , Toma wrote: > As the top of the page says, we need to finalize the list of things > TODO. hi guys, i'm not the dev so beg your pardon if things below are "out of scope". 1) after the review of a mentioned page (http://trac.enlightenment.org/e/wiki/Release) i decide to fill 'trac' with some more 'tickets'/(requests) instead of the page modification. assume that it's your (and not mine) decision to set a milestone to the Release. 2) there're no 'magic' word we're all aware about (no doubt that it ... you know...). here it is (in capital letters): == "SYSTRAY" == suppose that clear definition of our POV to this case is required. it's o'k not to make one and explain why. but Release of a Desktop Shell without a tray will attract less Users i guess. yes, Wiki FAQ advise to use 'trayer', 'stalonetray', etc., but references to the various discussions are unable to state the case clear. 3) annoying question related to the "color and font config modules". as it was mentioned by Raster: >thats what i meant - just wouldn't compile the color and font config modules. >they they wont appear anywhere. code will be there - just not being compiled or >used until its fixed. ok. but does it mean that all themes/(.edj files) which use custom fonts and/or "color_class:"-es will require maintenance? if "Yes!", then suppose that the info should be spread all over the community or only new default theme will remain usable (it's a nice option, but some may prefer other variants). 4) another "chewing gum" - "Should add lua support? (optional)" Just make a decision and say it. No/Yes - doesn't matter much (though the amount of maintenance if "Yes" will be sufficient). it's a pity that both VM's ('embryo' and 'lua') can't exist together. 5) last couple of days i'm using 'Ecomorph' and it's much more stable then "bling" module. suppose that "bling" should be improved (in terms of stability) or explicitly marked as 'unstable'. yes, FAQ tells that E17 doesn't work with composite, but it's an easy task for "bling" now to create a nice segfault of E17 :). offtop> http://en.opensuse.org/Ecomorph 6) as i mentioned in trac ticket #201 the "gap" exist in a window management between E16/eesh and E17/enlightenment_remote. it could be nice to eliminate this "mismatch" especially for the experienced Users of E16. 7) the "bridge" between "qt" <-> "edje" && "gtk" <-> "edje" still "under heavy discussion" suggest to create a couple of themes like existing "Clearlooks" (it's really nice) to match the major ones used by others. dunno about "qt" (don't use it here) but it's an easy task to copy a couple of most popular "gtk+" ones. thanks for your kind attention. regards, sda |
From: Carsten H. (T. R. <ra...@ra...> - 2009-01-31 22:56:03
|
On Thu, 29 Jan 2009 16:29:12 +0300 sda <dmi...@gm...> said: > On 09:04 Thu 29 Jan , Toma wrote: > > > As the top of the page says, we need to finalize the list of things > > TODO. > > hi guys, > > i'm not the dev so beg your pardon if things below are "out of scope". > > 1) after the review of a mentioned page > (http://trac.enlightenment.org/e/wiki/Release) > i decide to fill 'trac' with some more 'tickets'/(requests) instead of > the page modification. assume that it's your (and not mine) decision to > set a milestone to the Release. ugh. now i need to find all the tickets spread around with bugs and feature requests too... much harder that just reading the page and knocking off line items and deleting them. > 2) there're no 'magic' word we're all aware about (no doubt that it ... > you know...). here it is (in capital letters): > == "SYSTRAY" == > suppose that clear definition of our POV to this case is required. it's > o'k not to make one and explain why. but Release of a Desktop Shell > without a tray will attract less Users i guess. yes, Wiki FAQ advise to > use 'trayer', 'stalonetray', etc., but references to the various > discussions are unable to state the case clear. not happening. tray protocol/mechanism is broken as fare as e is concerned. > 3) annoying question related to the "color and font config modules". as > it was mentioned by Raster: > > >thats what i meant - just wouldn't compile the color and font config modules. > >they they wont appear anywhere. code will be there - just not being compiled > >or used until its fixed. > > ok. but does it mean that all themes/(.edj files) which use custom fonts > and/or "color_class:"-es will require maintenance? if "Yes!", then > suppose that the info should be spread all over the community or only new > default theme will remain usable (it's a nice option, but some may > prefer other variants). nothing is needed from themes - nada. simply users will not be able to fine-tune config for private DIFFERENT fonts and colors. they get what the theme gives them. > 4) another "chewing gum" - "Should add lua support? (optional)" Just > make a decision and say it. No/Yes - doesn't matter much (though the > amount of maintenance if "Yes" will be sufficient). it's a pity that > both VM's ('embryo' and 'lua') can't exist together. they can. the question is - do we want to ship with a vm/scripting engine we WILL drop in the future thus having a pain for people post-release of having to adapt stuff they built on 1.0 releases. > 5) last couple of days i'm using 'Ecomorph' and it's much more stable > then "bling" module. suppose that "bling" should be improved (in terms > of stability) or explicitly marked as 'unstable'. yes, FAQ tells that > E17 doesn't work with composite, but it's an easy task for "bling" now > to create a nice segfault of E17 :). not touching bling. compositing is scheduled for e18 - for e17 it's a "someone elses problem". you chose to use bling - you should take it up with bling's author/maintainer. :) e is not doing compositing itself until e18. > offtop> http://en.opensuse.org/Ecomorph > > 6) as i mentioned in trac ticket #201 the "gap" exist in a window > management between E16/eesh and E17/enlightenment_remote. it could be > nice to eliminate this "mismatch" especially for the experienced Users > of E16. removing almost all of e_remote. the window management features of eesh are of niche use and can be done by simply x tools without the wm. feel free to write these tools. :) no need to go add work for e17 release for something that has no need to be in e. > 7) the "bridge" between "qt" <-> "edje" && "gtk" <-> "edje" still "under > heavy discussion" suggest to create a couple of themes like existing > "Clearlooks" (it's really nice) to match the major ones used by others. > dunno about "qt" (don't use it here) but it's an easy task to copy a > couple of most popular "gtk+" ones. to be honest - gtk and qt are out of scope for e17 release when it comes to edje or evas. > thanks for your kind attention. > regards, > sda > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Toma <tom...@gm...> - 2009-02-13 21:27:35
|
So todays the day to finish all features. I know its a pain in the ass, but would it feasible to start suggesting an ultra-hazy alpha release date? My crystal ball is suggesting August-September. This may motivate people to actually work on these bugs if we have a set date to TRY to get these things done. Additionally, considering GSoC is fast approaching, so we might be able to get some more developers on board if we get accepted again. Might be a good idea to get a wiki together on how to get involved in E bug squishing so we can link to it for any prospective developers? Toma. |
From: Gustavo S. B. <bar...@pr...> - 2009-02-25 00:02:05
|
On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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 :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Toma <tom...@gm...> - 2009-02-24 23:14:51
|
> > 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. > Raster mentioned cleaning up config dialogs to function like the new-ish battery module config dialog. As you can see, its small, easy to understand and uses the toolbar widget. Just something to consider when making suggestions on this to make the dialogs somewhat uniform. > 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 :-) > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > |
From: Vincent T. <vt...@un...> - 2009-02-25 09:05:14
|
On Tue, 24 Feb 2009, Gustavo Sverzut Barbieri wrote: > On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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 |
From: Cedric B. <ced...@fr...> - 2009-02-25 12:47:23
|
On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri <bar...@pr...> wrote: > On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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 |
From: Thomas G. <th...@gs...> - 2009-02-25 14:14:16
|
On Wed, Feb 25, 2009 at 1:47 PM, Cedric BAIL <ced...@fr...> wrote: > On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri > <bar...@pr...> wrote: >> On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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. |
From: Cedric B. <ced...@fr...> - 2009-02-25 13:07:48
|
On Wed, Feb 25, 2009 at 2:01 PM, Thomas Gstädtner <th...@gs...> wrote: > On Wed, Feb 25, 2009 at 1:47 PM, Cedric BAIL <ced...@fr...> wrote: >> On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri >> <bar...@pr...> wrote: >>> On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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 |
From: Gustavo S. B. <bar...@pr...> - 2009-02-25 13:33:17
|
On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL <ced...@fr...> wrote: > On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri > <bar...@pr...> wrote: >> On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Cedric B. <ced...@fr...> - 2009-02-25 13:41:47
|
On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri <bar...@pr...> wrote: > On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL <ced...@fr...> wrote: >> On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri >> <bar...@pr...> wrote: >>> On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2009-02-26 03:32:51
|
On Wed, 25 Feb 2009 14:41:41 +0100 Cedric BAIL <ced...@fr...> said: > On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri > <bar...@pr...> wrote: > > On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL <ced...@fr...> wrote: > >> On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri > >> <bar...@pr...> wrote: > >>> On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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) ra...@ra... |
From: Gustavo S. B. <bar...@pr...> - 2009-02-26 03:49:48
|
On Thu, Feb 26, 2009 at 12:22 AM, The Rasterman Carsten Haitzler <ra...@ra...> wrote: > On Wed, 25 Feb 2009 14:41:41 +0100 Cedric BAIL <ced...@fr...> said: > >> On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri >> <bar...@pr...> wrote: >> > On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL <ced...@fr...> wrote: >> >> On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri >> >> <bar...@pr...> wrote: >> >>> On Wed, Jan 28, 2009 at 9:04 PM, Toma <tom...@gm...> 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: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |