On Mon, 19 Nov 2007 21:53:24 +0100 "Dr. Michael 'Mickey' Lauer" <[EMAIL PROTECTED]> babbled:
> Sebastian Dransfeld wrote: > > Peter Wehrfritz wrote: > >> But is it really reasonable to split ecore in such small parts? In > >> particular when you think on ecore_txt (1 function) or ecore_job (1 + 3 > >> functions). > > > Another point in splitting should be to make ecore_evas check engines > > runtime and not compile time. > > Yeah, I'd like to see that as well, i.e. for embedded systems. that's very hard. 1. each engine has a header file it installs. that defines the engine_info api (the struct contents) so at compile time if the engine headers are not there the support CANNOT be built. 2. the engine calls are specific for creating the canvases as they acept different parameters for creation. 3. runtime, if an engine is not available (even though it was, compile-time) the create of the canvas will fail, so it's safe to try, fail then try another engine. if you really want, ecore_evas_engine_type_supported_get() could also query evas for the engine availability runtime as well. as above - i don't use it. i just try to use the engine i want and if it fails i can exit or try another engine (eg try software_x11 - if that fails, try fb). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
