On Thu, Oct 20, 2011 at 1:24 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > > 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.
read again. I mean interfaces, these are used to provide multiple inheritance... There is no way to have multiple inheritance, by traditional definition, in C. All you do is using the "interface" concept that is orthogonal to the actual inheritance type. > > >> 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. yes, then you're replacing MMU and pagefaults with your own code... then you loose valgrind and gdb to help you. You work around one problem and creates another, unfortunately. > > 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. both have it. GObject using interfaces, PyObject using almost-traditional multiple inheritance. > > >> >> 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 > -- 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
