On Thu, 20 Oct 2011 11:37:29 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> 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 :-( we need more than simple inheritance. > >> 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. thats my point. its very common. we need to support this. real life ALSO says that we have REAL problems with objects being pointers. > 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. no multi-inheritance, and some other things from memory i don't like. i looked at it already. > >> >> 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
