On Thursday, October 20, 2011, Carsten Haitzler <ras...@rasterman.com> wrote: > On Thu, 20 Oct 2011 10:19:14 -0200 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > >> 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. > > we have a problem in elementary already because we dont have (multiple) > inheritance. we are duplicating api's like crazy.
Come on, we dont even use the simple inheritance! Btw, Sachiel already put the pointer in Evas_Smart_Class to allow interfaces. It would not even break the ABI. But Elementary needs to use proper inheritance to then use interfaces. who is doing it? I'd love to, but can't fund that myself :-( > >> Parts of it, like deleting the timer when object dies is a common pattern >> and indeed deserve a helper. Simple to do, useful. > > and if its at the core of every object we have.. then its trivial to glue any 2 > objects together and have slaves deleted when master is deleted. you can glue > multiple evas objects together this way - you can glue an animator to a timer. > glue a timer to a job. glue a job, 3 animators, a timer, to an evas object.. > etc. How many cases like that we have? I can find dozen thousands cases like mine in each GUI and app and libs. And if you really want to do this anyway, why not use GObject? It will provide all of that, binding tools and even Vala to help. PyObject is also an option. > >> >> 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 -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- 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
