On Fri, 13 Apr 2012 21:49:47 +0200 Jorge Luis Zapata Muga <[email protected]> said:
> On Fri, Apr 13, 2012 at 12:45 PM, Carsten Haitzler <[email protected]> > wrote: > > On Thu, 12 Apr 2012 16:44:46 +0200 Jorge Luis Zapata Muga > > <[email protected]> said: > > > >> Hello Tom, > >> > >> I haven't checked the code completely yet, don't have much time. Nice > >> initiative to share the development process, does not happen very > >> often ... but could you please share the "design decisions" you take > >> with this new OO approach? (Not from a code POV). > > > > well i can answer that. we have a poor-mans object model up in the evas > > layer - evas object + smart objects. this of course is limiting and doesnt > > cover things like ecore (timers, animators and other things), and is > > definitely way too heavy for such things as u need actual evas objects. it > > also is relatively limited. > > > > over the years we have grown a kind-of object model here and many different > > mechanisms to have callbacks called on objects. there are ecore event > > handles, evas object event callbacks, evas smart callbacks, edje signal > > callbacks, edje message callbacks... way way way too many different ways to > > "get called when an event happens" each with different prototypes u have to > > keep looking up. there is a lot more besides, and then there is elementary > > which is in dire need of multiple inheritance for several situations. in > > addition we have no current way to indirect object lookups to allow for > > compaction and crash protection. the point of this is to fix all of that in > > a simple base object system that also compacts our code and makes it easier > > to write and maintain, allows for better optimisation and cuts the costs of > > function entry that we currently have in doing magic type checks every func > > call etc. - we can amortise than now over multiple operations. also now > > string parent/child relationships so child object get deleted when parent > > objects go away etc. but this happens all the way at the bottom of the efl > > stack. not up in evas or elm land. > > yes, true, is kind of complex to manage all such events, signals and > objects on different libraries, but i suppose that if Elm would have > been decided to build on top of such libs and not be part of the libs, > i mean, hide evas, edje and ecore behind it, then this situation might > be simpler to solve. dont want to sound like trolling here, but etk > (maybe ewl too, dunno about it), did exactly that, someway it cloned > the gobject system and managed to hide all the internals of the > different core libraries, but it was doomed by the fact it wasnt using > Evas_Objects (or smart objects) as its main object abstraction, but > now such object system is required. the etk/ewl approach imho just didn't work well as it had to wrap everything. wrapping hurts. it just adds yet another layer that isn't really needed and everything *INSIDE* the wrap just looks odd compared to outside. moving object stuff all the way down the bottom stops that from happening. it will take a while for code to migrate over internally but you have to start somewhere. you will still have a wrapper layer that implements the current api for compatibility, but that's a necessary evil. > >> I'm asking because from the above comments you just explain what is > >> *missing* on your implementation, but given that I started some years > >> ago a project called "ekeko" (I think it is still under PROTO) which > >> wanted to solve this problem too and recently I've been developing > >> "ender" (which for me fits exactly on my OO needs), we might be > >> sharing several goals, or maybe not ;) > > > > ender is close, but it's string based properties don't handle actual method > > calls, and the strings hurt here. nice for higher up in the stack, but lower > > down it will hurt performance-wise. > > that's not accurate. ender does have, as you pointed out, a string > based property system and you have functions to interact with the > properties of an object using strings, like: > ender_element_value_set(Ender_Element *e, const char *name, ...); > which will imply a string -> property lookup, but you also have the > simplest forms: > ender_element_property_value_set(Ender_Element *e, Ender_Property > *prop, ...); which receives the property directly and no need for a > lookup, is just a matter to export on your lib such Ender_Property in > a similar way that ecore exports its events, i.e extern Ender_Property > * OBJECT_ID_PROP; did you add that since i last looked maybe 2 or 3 months ago? i actually can't remember where ender is. :) i don't remember seeing this. but also note that eobj isnt property based. its still methods - but implemented vastly differently gobject. > but, beside the question if ender fits here or not, im wondering if > the OO system is really needed as the base to build the core libraries after some experience with people new to efl, i have seen LOTS of examples of people using timers, animators and not managing them properly and ending up in bug-land, because they are not objects and they don't get cleaned up when the "parent" (eg the evas object they are animating) is deleted. i am convinced we need this stuff even at the basic ecore level. > on top of it, I mean, given that Evas already has a kind-of-object > sytem, Ecore has the same thing with its events and different sub evas objects are FAT. really fat. you don't want to use that as a base for any objects other than ones that are ACTUAL objects in the canvas. > systems, etc, or is better to wrap the already coded core libraries > into something more manageable from an application POV. But i guess > here that the real problem is Elm and its nature to be Evas Objects. and the wrapping bit - as above - imho doesn't help/work well here within efl. we are not wrapping a 2rd party lib we don't control - we are wrapping OURSELVES. it's time we stop doing so and just fix the root cause. > > so goals are: > > > > 1. unify callbacks into a single prototype > > 2. unify ref/unref/delete etc. > > 3. allow for multiple inheritance as well as single > > 4. break out the varargs to be able to cut the cost of object checks > > (magic/null etc.) over multiple operations all in 1 go > > 5. allow for greater object optimisations so you can create an object AND > > set all its initial state in 1 function call and thus avoid lots of > > needless state transitions as you set things up. its a much more compact > > way of doing freeze/thaw without the footwork > > 6. put in the layer to allow for object indirection so object pointers can > > become not just a pointer to the obj memory, but a double-indirect (obj **) > > OR even an ID lookup in a table which can allow for complete safety and zero > > crashes in object access. as more safety here comes with more overhead - our > > varargs fun lets us spread that cost out over maybe 3, 5 or 10 calls, > > ultimately actually lowering our costs below what we currently have in efl. > > > > bonuses: > > 7. we get some method introspection while we're at it > > 8. we get callback/signal documentation too from the base up (not just smart > > callbacks on evas objects) > > 9. object indirection allows for memory compacting to kill off a lot of the > > fragmentation i have seen crop up in apps (like e17) over time as it runs. > > 10. much better tracking of references > > > > sure, but the above are the goals that every OO system wants, and from > the list, why not picking up gobject directly? and dont invest time on > doing yet another object system? Something wrong with gobject? (beside > the fact that it begins with 'g' of course ;)) you REALLY need to look at gobject vs what tom posted. firstly eobj is varargs based. you dont have to "find the class struct for that object type, then call the func from that class struct, PER method call". it is a single call with app methods thrown on the stack. it's more efficient for both call overhead and the object design itself as there is now an implicit ability to batch operations, much less verbose - so it saves typing and is easier to read. it saves writing gtk/old efl style c wrapper funcs around each method call (more overhead). look at some of the examples, then extrapolate. look at: Eobj *bt = eobj_add(ELW_BUTTON_CLASS, win); eobj_do(bt, EVAS_OBJ_POSITION_SET(25, 25), EVAS_OBJ_SIZE_SET(50, 50), EVAS_OBJ_COLOR_SET(255, 0, 0, 255), ELW_BUTTON_TEXT_SET("Click"), EVAS_OBJ_VISIBILITY_SET(EINA_TRUE)); eobj_event_callback_add(bt, SIG_CLICKED, _btn_clicked_cb, "btn"); right now in that example thbis SHOULD be a single function with eobj_add() accepting varargs too. the callback_add should also be part of the varargs (take note tom!) so ultimately it will be this: Eobj *bt = eobj_add(ELW_BUTTON_CLASS, win, EVAS_OBJ_POSITION_SET(25, 25), EVAS_OBJ_SIZE_SET(50, 50), EVAS_OBJ_COLOR_SET(255, 0, 0, 255), ELW_BUTTON_TEXT_SET("Click"), EVAS_OBJ_VISIBILITY_SET(EINA_TRUE), EOBJ_CALLBACK(SIG_CLICKED, _btn_clicked_cb, "btn")); vs: Evas_OBject *bt = elm_button_add(win); evas_object_move(bt, 25, 25); evas_object_resize(bt, 50, 50); evas_object_color_set(bt, 255, 0, 0, 255); elm_object_text_set(bt, "Click"); evas_object_show(bt); evas_object_smart_callback_add(bt, "clicked", _btn_clicked_cb, "btn"); so same # of lines, but lines get denser. if we had namespacing within funcs we could remove the EVAS_OBJ_* etc. stuff, but alas we don't. now the important thing to note here is. the current model - the gtk model. the ender model, is to go in and out of the efl lib 7 times. the eobj model is to do it once. that means object indirection and checks happen once, not 7 times. ALSO the object can EASILY defer generating events (eg a move or resize callback) until the function is done. this is especially useful for elementary where you may often create a widget, THEN set the style. right now object is created, edje files created internally, then return, then come back and change style - which means change edge group/file, so re-load new edje file and do a bunch of memory gymnastics. with the eobj scheme we can add an implicit "flush" (per class in an object which had methods called), to be done at the end to easily defer changes. thus the eobj code ALSO had an implicit freeze() and thaw around it. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
