does it compile and work on windows ? if it compiles with "-ansi -pedantic", there will be good chances that it will work.
Vincent On Mon, Apr 2, 2012 at 11:58 AM, Tom Hacohen <[email protected]> wrote: > 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 ------------------------------------------------------------------------------ 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
