On Wed, Dec 5, 2012 at 2:14 PM, Flávio Ceolin <[email protected]> wrote: > On Wed, Dec 5, 2012 at 12:41 AM, David Seikel <[email protected]> wrote: >> On Tue, 4 Dec 2012 23:44:48 -0200 Gustavo Sverzut Barbieri >> <[email protected]> wrote: >> >>> On Tuesday, December 4, 2012, David Seikel wrote: >>> >>> > On Tue, 4 Dec 2012 12:24:28 -0200 Flávio Ceolin >>> > <[email protected] <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.
which is a cotradiction with the merge as the merge requests some dependencies, now :) Vincent ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
