Jorge wrote:
> Some time ago i had another idea that i've been implementing, some of
> you already know enesim and ekeko, some other dont, let me explain why
> i think adding this to evas is not good imho.
>
> One of the main reasons of not releasing software is that it evolves
> too fast or it doesnt stabilize enough to make a stamp on a specific
> version and release it; but that is a direct consequence on what your
> lib wants to achieve. So im partisan of doing small things with solid
> API, of course not too small that it will make the lib itself dumb,
> but keep the objectives clear.
>
> Adding all of this to evas itself not only will make evas more bloated
> but more unmaintainable and of course the release time will be
> delayed, i'd like to share another idea that might help us achieve the
> same goals jose is trying to do, but keeping the api itself of evas
> clear enough.
>
> We are always on the objects/engines problem, how to support more
> objects features and how to add more engines and the truth is that the
> model we have right now doesnt scale too god, we are duplicating code
> here and there for engines and we are limited with current objects for
> fast drawing operations and smart objects for outsiders drawers whcih
> might not be as fast as an insider object.
>
> The idea is to flip the concept, totally. Not make the fast objects as
> inside objects and the engines as modules, but do both as modules with
> a different approach, mainly object+engine approach. The idea can be
> that an object (being a module or a library) register with evas for an
> specific object name and engine name (of course both the module and
> evas should share those names) like:
>
> evas_object_register(const char *name, const char *engine, Evas_Obj_Func);
>
> where the functions struct is something we already have but specific
> for that engine type. For this to happen, evas should export the
> needed functions and abstract the common code into exportable
> functions too.
>
> Use cases:
> - An engine doesnt support an object you are requesting natively?
> Evas should always fallback to software engine in that case, the
> drawing should be done on a user writable buffer and use the software
> engine there. So every engine should be reduced to a minimal set of
> functions:
>
> redraw() // redraws part of the engine output buffer
> blt_buffer() // blit a buffer into engine output buffer
> get_buffer() // get a buffer that the user can draw to
> get_native_buffer() // get a native surface so the object-engine can
> draw directly there
>
> - You want to build a private engine?
> You should set this engine's minimal functions, if you also want to
> provide accelerated objects for your engine, register a new object
> with your engine's name and fill the needed functions
>
> If we can settle down the above, which i think won't be that difficult
> to stabilize than the object's api, we would have gain a lot on
> flexibility. And then the object's api can be stabilized.
>
> Why i started enesim? because of the above cases, allow the user to do
> fancy graphics objects using enesim's primitives and direct rendering
> approach and also for easy benchmarking of the software engine.
>
> Do you think is a good idea?
>
Yes, I think it is a good idea (though there are also other possibilities
for realizing such a generic concept).
However, there are two things to consider here:
One is that you still eventually need some sort of api(s) for 'objs' that
you may want to support to start with in some 'canvas' model -- and that
includes
a semantics that would be consistent, and basic/standard kinds of gfx concepts
that are well-known and widely used.
The other thing is the time and distance from such a more flexible
approach
to what's there now -- how to make both-ends-meet, or forget one and continue
with
the other.
These are difficult questions to pin down and decide on.
Let's consider the first part above only, and let me ask you this: What
are the successful/modern gfx *apis* out there used for building guis, what are
their models, what are their primitives, how do they deal with extensibility
or custom rendering. Take a look at say Flash, Silverlight, and Qt..., and let
me know what you see there.
There are others as well, but if you look at just these and give a
synopsis
of what's there, we can compare with evas and/or some possible other thing and
continue with greater insight and foresight. :)
____________________________________________________________
Click for free info on online degrees and make up to $150K/ year.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nlXFvWpEiH1JgkNuaQWtD3XAbh0bvIMLSauNEiAzQFFY4P3/
-------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
