[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas & Evoak future changes



On 8/24/06, jose_ogp@juno.com <jose_ogp@juno.com> wrote:

   Jorge writes:

<snip>
But to export evas' internal structures, especially the engine
funcs and such.. is really dangerous at this point in time, unless
you're willing to freeze evas' capabilities, or just use this as a
starting point and change things as one goes along until one is
satisfied.
you are right, if evas exports its internal function not only a change
on the API would mean a version bump, but also a change on the
internal functions/data structs.

        So, the gfx parts of the engines (and some that are not
directly gfx aspects) are really mostly a bunch of functions that
apply to each object type, and some core functions that apply to
all object types, and some that apply to display-target aspects.
So, the 'engines' are in large part just the obj types themselves.
Extending the engines is thus largely equivalent to extending
the set of object types, and possibly the global gfx context.
        If one can suitably set that up, then there's no need to
export a lot of specific internals to get modularization.

im not sure i actually understand what you are trying to explain :)
maybe you mean that if i setup correctly an API for "object engines"
there's no need to export internal functions? you are correct, and
then is my fault to no explain myself correctly =)
on the mail i sent there two different things:
- make an object engine
- export internal functions
(note that the last isnt needed for the first)

i'll explain a little more on what i did with my local version:

in current evas each engine should declare a Evas_Func and fill the
functions (this is the engine API). so the idea is to make another
type of engine with its own type of functions struct, like
Evas_Engine_Object_Func and make current struct like
Evas_Engine_Render_Func. note that the comparision if the engine is of
type render or object is done at the evas_engine subsystem i explained
on the previous email. the type of functions an "object engine" should
declare in its struct are for example a function for an object_move,
object_resize, etc. there's no point that a normal engine (render)
must define those functions too. so if i understood correctly this is
the engine API which i already implemented in my local version.

about the internal headers thing, is to actually have the possibility
to use evas internal functions on modules out of the main source tree,
not only engines, but loaders, savers, even objects.

dont know if this is clearer or it isnt even the answer you were expecting =)

regards,
jorge.


        Again, I'm not sure what I could tell you right now except
that it's great stuff and dangerous stuff at the same time..  :)


   jose.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel