Re: [E-devel] edje_cc dependencies

[Carsten H. (T. R. <ra...@ra...>]

On Sun, 18 Apr 2010 19:31:45 +0200 mobi phil <mo...@mo...> said:

> On Sun, Apr 18, 2010 at 2:49 PM, Michael 'Mickey' Lauer <
> mi...@va...> 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&#174; 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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...