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
