On 23/08/2011, at 11:16 PM, Thiago Macieira wrote: > On Tuesday, 23 de August de 2011 14:07:46 Philip Ashmore wrote: >> For example image file format support, you instantiate a mapping object that >> looks up the registry and loads the implementor for that format if it's not >> already loaded. > > What registry are you talking about? > > This is exactly the point that Stephen was trying to make: we need a way to > detect which plugins exist and what they do, plus this should be cached > somehow. >
The system chosen also needs to support adding plugins at runtime. For example, a package might get installed and it knows about the plugins that come with it, so it provides registry info for these (whatever that registry functionality ends up looking like). However, the package happens to be a large framework that supports users providing their own plugins *for the framework* and where those plugins are more specialised than Qt's plugins. The framework plugins might have their own Qt plugins as well and it is these Qt plugins that need to be findable at run-time even if they are not in the framework's own Qt plugin registry. Currently, the QT_PLUGIN_PATH environment variable provides the necessary support for this, but if there's a different mechanism introduced in Qt5, it should provide something similar. Maybe just an environment variable that contains a list of additional registry files to read? -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
