On Sun, 18 Apr 2010 19:31:45 +0200 mobi phil <m...@mobiphil.com> said:
> 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...
why is there glx, agl, wgl, ... why? :) same reason. look at the actual
functions. notice the parameters are different? eg an x11 based canvas can have
a parent window ID - but a fb one cant - hell it cant even have a x, y position
- as it takes over the fb... that necessitates different init parameters.
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.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
