Jorge wrote: > Hi all, > > Here i attach a patch that wraps all the calls to > obj->layer->evas->engine.func inside the objects into a function > itself. So instead of doing evas->engine.func->image_border_set you > should call evas_engine_image_border_set. It looks like a cosmetic > patch, but is the base for a larger rewrite of Evas internals. > > As Jose has been saying (and myself) for some time now, Evas *needs* a > refactor on its internals, this is the first step in the path to allow > objects to be built outside Evas which will imply to build a good and > defined interface between objects, engines and the canvas system. > Right now the evas_engine_xxx functions are just on a private header, > later those can be as well exported and let users build their own > objects based on this accelerated primitives. > > I can commit myself this patch (the text objects are still missing > btw), but i prefer to know your impressions before. > >
I've argued one side of the coin on this issue of an extensible mechanism for evas objects which can get 'close-in' for better efficiency and flexibility, and suggested a simple initial approach that can be realized now... But let me also argue another side of this coin and reply in part to your proposal here. One reason I've not mentioned this much recently (til now when I saw carsten and gustavo wanting to add new objs and their apis to evas lib proper) is that it does have its 'issues' with current evas. Basically, evas is still too immature in many ways and just not ready to 'export' much of anything - not unless you're willing to constantly keep up with possible changes of various sorts. This is why I suggested an initial approach that does require objs to be built against evas internals (much like e17 modules). I'd leave a more advanced approach which exposes some kind of (stable) abstract immediate-mode gfx api, or whatever, for later when things are well-defined enough. In other words, I'd suggest a two-tier approach for evas object extensibility, object modules say (which do require access to evas internals) and obj plugins say (which can be defined without such access). From a user's point of view though, there's no difference between these two.. one still needs to include the headers for the obj (or lib of objs) that one wants to use. Another 'issue' to keep in mind here is how well the rest of the current efl can adopt/adapt to such a new capability. It can potentially bring a wealth of stuff, but only to those libs/apps which have some ability to incorporate extensible/ pluggable/modular aspects without too much trouble. Take edje for example. There are several ways one can get it to use such evas obj extensibility.. the more direct ways would take quite a bit of work, but one can do it fairly easily if one adopts various indirect ways - eg. have a generic OBJECT part which references its own description, which in turn could either be in a separate file (possibly even using a different format than edc), or in some part of the eet itself. The descriptions would then be loaded/realized by associated edje plugins that know about the type of object being dealt with. etc, etc. In any case, I really don't know exactly what you envision here for later so I can't really say much more about your proposal.. except that I'd be concerned about exporting evas engine functions in any serious way. Maybe you could some more specific details as to what you have in mind for things here? PS. I can give you more details on what I've already suggested, even send you a version if you like, but it's really very simple as I've already described before.. it's simple largely because it demands that the object modules have access to evas internals. It'll give evas extensibility - one way of realizing object modules - but at the price of this dependence, and if the internals change enough then your object may become crap. So, it means such objs always have to keep up with the evas version and be updated, ie. much as is happening now with evas engines from my attempts to extend its gfx capabilities. ____________________________________________________________ Free information - Learn about Beauty School. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oLm4N6idRExqGifE53NLvrOcAwe4i3OV0CdvbkdYJloqjLj/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
