On Thu, 20 Oct 2011 14:32:32 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> 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. it is possible to do it in C. > > > >> 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. there's a big difference in behavior on fail. pagefault == app disappears with everything the user was doing. with indirect referencing via id's stashed into the pointer, you gain the ability to soft-trap and "march on" without such drastic behavior. it's the same thing, on a finer-grained scale, as having your whole system crash every time an app did something wrong, vs, just having that 1 process crash. 1 process going down is more graceful. we can do this for EFL too. REALITY is that i see on a regular basis developers who DONT use valgrid or gdb - they simply get a backtrace when a crash happens - without parameters or listing. just basic symbols.. on a GOOD day (often not even with symbols) then jump up and down and want you to fix their bug. reality is that the vast majority of those developers don't even know what valgrind is, or gdb, and they never have source installed so they cant print variables in gdb, list lines and dig through memory. you don't see this so your view is one of "well everyone uses valgrind and gdb and has full source traces". that view is wrong. in addition we get the ability to re-compact memory to combat fragmentation which is a REAL problem. i've seen 50% of memory "unused" due to fragmentation. (that means when top/ps says you are using 6mb of "rss" (minus shared), you actually have allocated closer to 3mb, the other 3mb is just wasted fragmentation). reality is libc and the mmu don't go making holes in our memory space where there is free space and hand those holes back to the OS if they fill entire pages. they keep those entirely private to the app. they just expand the upper water mark. > > > 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. 1. pyobject will not be used. no way on this earth we are dragging in all of pyhton JUST to get some very simple infrastructure for objects. 2. show me how gobject does this. and are you then going to do the work? also we don't get indirect referencing with gobject. > > > >> >> 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 > -- ------------- 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@Cisco 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
