> 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
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?
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!