[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas & Evoak future changes
> 1. reorder the headers:
> every subsystem has its own header, no more one huge header
> (Evas.h, evas_private.h, evas_common.h). as the main idea of this
> is to allow objects, loaders/savers, engines to be able to build
> outside evas, we need a way to export internal API. So for example
> there will exist beside evas_callbacks.c an evas_callbacks.h, etc.
> 2. support for internal, api headers (Evas.h, Evas_Internal.h)
> the way of how the evas apps current include evas headers must not
> change. so the normal apps will still include Evas.h using the
> evas-config --cflags, there's no change there.
> but now the content of Evas.h is some kind of superheader including
> the subsystems headers or some generic typedef in case of the api
> (to keep the data structs private)
> Another possibility, instead of this superheader thing, is that
> in the case of third party module, there could be a preprocessor
> define like -DEVAS_DEV to include all the private structs.
> the concept is similar to the linux kernel. talked to raster about
> this, and he doesnt like the idea too much, but in my opinion is
> cleaner but a bit more complicated, than having a evas_private.h with
> all the private data types there.
> 3. support for remote engines or object engines (havent decided the
> name yet, on my tree is REMOTE_ENGINE/RENDER_ENGINE), think is best
> to call it OBJECT_ENGINE. what does it does? its just layer above the
> obejcts interface, whenever a object_* function is called also the
> remote engine functions get called, this will allow evoak to work
> nicely (as it currently works here).
> 4. creation of evas_engine:
> this will be an interface between evas and its rendering/remote
> engine.imho the evas->engine.func->foo() approach isnt good enough,
> better use just evas_engine_foo to keep it secure (i.e comparing
> against null) and to use a generic engine (software) in case that
> a render engine doesnt support a particular callback. so the
> inheritance stuff should be rewritten in some way, because the
> software engine will be already a fallback engine.
> 5. add an engine data to objects,
> for things like ids on objects from the engine side, better this
> way than having evas to handle ids for objects (autoincrement,
> initialize, etc).
> 6. i think a good idea is to have some kind of prioritization for
> engines, having to update all the engines when some api change even
> if the engine is not used at all in any app, is pointless. so as
> evas in this state will allow engines to be built outside, i think
> is a good moment to move unused engines outside main evas tree.
> 7. support for the new engine api raster and jose have been talking
> about, dunno exactly what is the plan, would be a good idea to share
> that :)
> 8. make objects real modules. maybe include the pre-post render too?
> 9. anything else?? in the future would be nice to have evas data
> types in a common place instead of evas, to allow other non-
> graphics apps to use those. maybe merge them with Ecore_Data?
> i know currently there's a circular dependency (Ecore_Evas) but
> in the future would be a good idea.
> when points 1-5 are done, ill commit the new evoak code. just note
> that i wont be able to commit much things until mid of september,
> as im finishing the university (finally) and have no time at all.
> but we have a good time to discuss things, and implement in a good
> any comments about this ideas/plan or addition of new ones would
> be appreciated. bye!
Oh man, I don't know what to tell you. It's great work, and
many of the things you mention here would be very nice to have..
structuring of headers, public and private, so as to have a less
monolithic system, ecore based data structures used in evas, and
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
I did some of this a while ago, and stopped when I realized
just how much I was going to need to change in order to get things
like obj clipping, stroke/fill aspects, rotation/shearing, etc.
The thing is, there's no way to really know for certain
exactly what you're going to need until you come close to actually
implementing every aspect that you want.. I've come pretty close
to getting done most things I want, but there are still some
The engines use a global gfx context that holds general
gfx info about how to render things (color, clip, etc), and then
on top of that, each obj may have specific info that it needs to
render itself (eg. borders for images). Some of these can be made
a global gfx context for that type, some may be needed on a per
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.
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.. :)