On Sun, Apr 18, 2010 at 2:49 PM, Michael 'Mickey' Lauer <
mic...@vanille-media.de> wrote:
> Am Sonntag, den 18.04.2010, 06:09 +0200 schrieb Vincent Torri:
> > 2) edje_cc uses only the evas buffer engine. Isn't it time to split the
> > monolithic Ecore_Evas_Engine structure and dlopen modules ?
>
> Something like that would be appreciated. Right now in OE we have the
> problem that we would have to build two versions of EFL, one for
> framebuffer-and-X11, and one for framebuffer-only. Although the
> framebuffer-and-X11 version runs fine on pure-framebuffer systems, it
> always links to the X11 libraries thanks to pkgconfig.
>
Just in two sentences, maybe you could explain why the backends are not a
sort of "polimorfic". For example in elementary why do I have to write
switch( backend)
{
case FB:
****_fb_win_new( ,.p,.p,.);
case SDL:
***_sdl_win_new( ...);
}
instead of just blahblah_win_new(p, q, z); this is telling me that you have
nice abstractions of the backend, however you do cary with you the
dependencie up to very high levels...
If the backends do not have some special feature, then they should provide
that or, etc. etc.
Backend dependent settings should be provided on "other " channels, rather
than during _win_new calls....
do not want to play the inspector, etc... just wandering what is the reason
for this design decision.
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
