On Wed, Dec 5, 2012 at 12:41 AM, David Seikel <onef...@gmail.com> wrote: > On Tue, 4 Dec 2012 23:44:48 -0200 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: > >> On Tuesday, December 4, 2012, David Seikel wrote: >> >> > On Tue, 4 Dec 2012 12:24:28 -0200 Flávio Ceolin >> > <flavio.ceo...@profusion.mobi <javascript:;>> wrote: >> > >> > > I have recently committed in IN-EFL/ecore some patches >> > > implementing support for loadables modules. It makes the engines >> > > been loaded when they are needed. I did not break the api, so >> > > each engine still has its own api. It's far from ideal, should >> > > exists one api used by all the modules but at least until the >> > > next version, we need keep the api. >> > > >> > > The modules (engines) usually exports just on symbol, the "new" >> > > function, the other necessary functions are in the engine's >> > > interface. >> > >> > I'm a bit confused here, why is this needed? Isn't it the case that >> > more often than not there's only one useful engine that is >> > supported by the hardware? And not like you will be moving a >> > window on the fly from X11 to fb? Certainly I don't think anyone >> > will be using X11 and Windows engines in the same run of their >> > proggy. How is this supposed to work? What use case is there for >> > it? >> > >> > I can understand if it was for image loaders & savers, and other >> > stuff, that makes sense, but engines? >> >> >> Before linking to ecore_evas built with x11, wayland and directfb >> would bring all those libs even if just buffer engine is used. Also >> if you built with them, you could not remove x11 or wayland >> afterwards. >> >> With the new infra, ecore_evas behaves just like Evas and each engine >> is a separate shared object, will just bring deps as its loaded. Can >> be removed from the system without breaking dynamic linkage. > > Ah that makes sense. The way it was described sounded more like "one > app can load and unload various engines at run time on the fly" to me, > which just sounded odd.
The main reason to support it, it is what raster said, add and remove support for engines without need rebuild the libecore_evas. It's also pretty good for the packagers because they don't need build with many engines enabled by default increasing the number of dependencies. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > Flávio Ceolin ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
