On Thursday, October 20, 2011, Carsten Haitzler <ras...@rasterman.com> wrote: > On Thu, 20 Oct 2011 08:38:18 -0200 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > >> I'd agree with discomfitor about his points. There are many widgets that are >> about different themes to the same concept and could be simplified (toggle, >> check, ... Selection of items...) > > toggle and check are actually different. check has label_icon+ on/off state. > toggle has 2 named states (a, b) with label+icon. check has no concept of named > states at all. you could make a superset of it and roll it into check i guess... > >> As I said many times I'm against eina-object. Not able to explain it in >> details from a phone, but I can try later if needed if no one else will >> >> Last but not least I want some helpers in ecore_evas to manage lifetime of >> timer, idlers and so to an Evas_Object. Do it now or later? > > later, but that was the point of eina-object in the end. to tie together ALL > these things. also provide a "indirect ptr" ref no longer direct reffing ptrs > (index+table) and ability to have properties, methods and multiple inheritance.
I know and that's why I dislike it. You're trying to solve the problem of people don't know C in C. It will bring clusterfuck to eina and EFL. Just let these things to high level languages. Parts of it, like deleting the timer when object dies is a common pattern and indeed deserve a helper. Simple to do, useful. > >> On Thursday, October 20, 2011, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > On Thu, 20 Oct 2011 04:04:38 -0400 Mike Blumenkrantz <m...@zentific.com > >> said: >> > >> >> On Thu, 20 Oct 2011 15:51:01 +0900 >> >> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: >> >> >> >> > Hey guys. time to talk of our next release cycle. this meant 1.1 of >> most efl >> >> > libs (and 1.5 for eet). this means we have lots of bug fixes and new >> >> > features here. i'm currently talking about: >> >> > >> >> > eina >> >> > evas >> >> > ecore >> >> > embryo >> >> > edje >> >> > efreet >> >> > e_dbus >> >> > eeze >> >> > >> >> > now coming AFTER this we want elementary to go 1.0 - so this is the >> last >> >> > change we have to "break api's" in elementary. >> >> > >> >> > e17 itself is an app so api is "not relevant" here, but we also want to >> work >> >> > full steam ahead on e17 release too. >> >> > >> >> > what i am proposing is that everyone finish their "pending work" for >> >> > everything above in the first list and get all pending changes to elm >> >> > upstream asap as well. i want to call a "2 week merge window" for core >> efl >> >> > (above) and then 2 weeks of bug fixing, then release. merge window >> starts >> >> > next monday (24th of october). that means from the 7th to the 20th no >> new >> >> > features can be added to trunk, only bug fixes. >> >> mmm this may be tough for eeze since supposedly users are having a lot of >> >> trouble with eeze mounting in e17 and I can't reproduce their problems. >> It >> >> would be great if I had some edevs working with me to test this so I can >> get >> >> bugs out. >> > >> > i haven't spotted bugs of late... >> > >> >> > i am opening the floor to anyone who thinks other libraries in svn >> should >> >> > also get the 1.0 treatment too - ethumb? epdf? emotion? >> >> I could prep esskyuehl for a release if people think it would be useful >> to >> >> have as a released library. I only have one or two trivial things to add, >> and >> >> it has been otherwise unchanged since May/June. >> > >> > no - leave that. it's still in proto and it actually isn't used by any of >> > e/efl elements currently, so no rush there. >> > >> >> > >> >> > some notes: eina will not have any eina-object model enabled for 1.1. >> evas >> >> > will have all the evas-gl stuff disabled in build and install for 1.1 >> as its >> >> > not stable yet. any more notes people have to throw in? >> >> > >> >> I think if we work on an elm release after 1.0 (which would be starting >> in >> >> December?) it will be a big mistake. Elm right now is a giant >> clusterfuck, so >> >> we should probably do the following instead of going straight for the big >> 1.0: >> >> * widget/feature freeze: NO MORE WIDGETS. PERIOD. there's too damn many >> as it >> >> is and QA on them is terrible. >> > >> > well this is all part of 1.0 path. we can just ignore going 1.0 forever if >> u >> > want and not do this... :) >> > >> >> * fix all existing widgets to work as intended: I say this in the >> general >> >> sense as there are tons of widget api functions which do nothing, have >> >> unintended side effects, or break the universe altogether. >> > >> > list please. (of api's not working(right)). >> > >> >> * review all existing widgets and apis: we may decide that some widgets >> suck >> >> and should be removed. remember that anything we ship with 1.0 is a >> widget >> >> that we have to support FOREVER. so, for example, this means that >> >> -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
