On Mon, 02 Apr 2012 12:58:21 +0300 Tom Hacohen <[email protected]> said:
i have some more things as my brain churned that i didn't add to my previous mail: 15. eobj_generic_data_* ... i really think this should support passing in a free func for generic data (NULL == dont free it), and previous egenric data is auto-greed if u set new data on top, same when u del - dont bother returning the pointer to it except on get. ALSO for generic data - can u provide a TYPE param - string, opque, eobj, opaque list, object list etc. types. opaque is unknown to eobj, but string can be used to account for memory objects and eobj can be used to have eobj auto unref attached generic data if its another eobj or list of eobj's. this would come it very handy. 16. eobj_event_callback_add() can be a macro imho. :) 17. maybe we can shorten callback to cb for brevity, also other full words might be shorter? opinions? save typing? generic_data -> gdata? ... 18. ok so we have callbacks that are of course called in-line in the stack. i'm mulling over if we should use the same callback system to POST events (messages) on a queue and then to be able to process them later as part of the ecore event loop. you will have to register a message queueing func with eobj - but eobj can handle reffing the target obj whenever u pose a msg cb and unreffing when msg event is finished in the queue. this can definitely help out here. now the obj can choose if it wants to call cb's inline or defer on the event queue... :) in fact this can even get quite smart - if in the mainloop it queues, if from a thread.. it can use the ecore async infra to send the cb's to the mainloop as messages... oooh baby... :) 19. and speaking of threads... i am wondering if maybe.. just maybe... we might not want to provide some locking/unlocking infra for eobj? it probably needs to handle recursive locks WITHIN the same thread... :/ let the flames begin! 20. pants on. > Dear, > > As some of you may know, my team and I have been working on Eobj, a new > objecting system for EFL. The current concept of varargs and having > eobj_do (you'll see what I'm talking about) was suggested to me by > raster and cedric, but I believe someone else deserves the original > credit, so please, if you know who I should be giving credit to, let me > know. > > I uploaded my current Eobj code to: > http://www.enlightenment.org/~tasn/eobj.tgz > Please feel free to take a look at the "lib" and at the examples in the > examples dir. This example code uses cmake, because that's what I find > most comfortable to work with, but the final version will be integrated > into EFL and will use autotools, or in other words, please don't bother > commenting about the build system. > > It's done and can be integrated into the EFL except for a couple of > things that are not yet decided: > 1. Thaw/freeze are not implemented yet > * Do we want to be able to freeze per object or globally to all > objects? > * Do we want to be able to freeze per signal or just the whole > object? (freezing just per signal can be risky because there might be other > signals and applications that expect certain signal sequence and failing > to block all will cause inconsistencies). > 2. There are still some slow paths - will be fixed as needed. > 3. I'm still uncertain about ref/unref + weak-ref + named-ref. > * I'm not sure yet about which kinds of refing we want. I'm pretty > certain we want named refs and "object" name refs (i.e linking between > objects). And I do believe we need weak ref/unref, but again not yet > decided. > 4. Many cases are not checked for validity and are just allowed. I plan > on having 2 modes, one for checking those, and the fast mode that will > just be fast. Possibly by having a compilation option + env var to turn > the checks on. > 5. No docs/proper internal naming yet, but API and examples should be solid. > 6. Currently the order of functions called is: object functions, mixin > functions and only then, composite object functions - should decide if > that's what we want. I like it. > 7. Mixin constructors are not called ATM. > * Will be fixed. The reason it was not done yet is that MIXINs are > 2nd rate citizens, as we don't yet have a use for them in the EFL. > 8. Currently only classes have data, not mixins. - Will be extended. > * I'm thinking about just letting them use the generic data and make > the common case faster... > 9. I plan on adding a signal indicating signal callbacks > addition/removal. - I.e you'll get a "some registered to 'resize' event" > signal. > * Very useful in many cases. > 10. Static class method IDs will be added soon. > * Raster suggested a cool idea that will help speed things up, which > is static IDs. It's not done yet, but it's 99% supported. > 11. Class type and all of that handling is not yet final. > * Currently you have a class type of either: EOBJ_CLASS_TYPE_REGULAR, > EOBJ_CLASS_TYPE_REGULAR_NO_INSTANT, EOBJ_CLASS_TYPE_INTERFACE, or > EOBJ_CLASS_TYPE_MIXIN. I'm not sure if we need more, or if it should be > ditched. > 12. Missing a flush function after eobj_do. - I plan on adding a "flush" > (I need a better name) function that will be called at the end of > eobj_do automatically. This will let us defer changes in an easier manner. > * I'm not sure about this one. In one hand, it makes it easier to > defer changes, though on the other, it's deference is not optimal, would have > been better to just create an infrastructure that will let us do better > deference of changes. > 13. Missing a way to group set/get. > * I plan on making a way to say "set and get both modify the same > property" which is not yet implemented. > > Please comment on the API (either the class API or the actual usage API) > and especially on the bullets I wrote above. > > Please also take a look at the elw_boxedbutton "widget" in the evas > example which shows the API for handling composited objects. > > Also, we are also working on automatic eobj bindings generation for > other languages, so if you have anything to comment on this matter as > well, please do. I see this as one of the most important parts of this > change. > > There is one noticeable hack in the evas example: the > eobj_evas_object_set/get functions. They are only there because we don't > currently use eobj in evas, but will be fixed "automatically" once we do. > > Bug reports, comments, suggestions, or whatever are more than welcomed! > > -- > Tom. > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- 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
