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

[E-devel] Evas & Evoak future changes



hi ppl,
this are my ideas i actually have implemented in a local version of
evas, i wont do a direct commit for everything i have, instead ill do
small commits to actually allow raster to read the commits and for
better understanding of what im doing. also evas has changed several
things in the past few months and i havent sync with them.

so here are the changes:
(already done, in no particular order)

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)
currently the headers are installed all in one dir like:

ls -l $prefix/include/Evas*
Evas.h
Evas_Internal.h

ls -l $prefix/include/evas/
evas_engine.h
evas_object_image.h
  ...
or maybe better to have all of them in $prefix/include/evas/?

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. So each header should
have something like this:
#ifdef EVAS_DEV
/* private data */
#else
/* public data
#endif

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).

(todo...)
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 way.

any comments about this ideas/plan or addition of new ones would be
appreciated. bye!

turran.