| Home · All Classes · Modules |
The QPluginLoader class loads a plugin at run-time. More...
Inherits QObject.
The QPluginLoader class loads a plugin at run-time.
QPluginLoader provides access to a Qt plugin. A Qt plugin is stored in a shared library (a DLL) and offers these benefits over shared libraries accessed using QLibrary:
An instance of a QPluginLoader object operates on a single shared library file, which we call a plugin. It provides access to the functionality in the plugin in a platform-independent way. To specify which plugin to load, either pass a file name in the constructor or set it with setFileName().
The most important functions are load() to dynamically load the plugin file, isLoaded() to check whether loading was successful, and instance() to access the root component in the plugin. The instance() function implicitly tries to load the plugin if it has not been loaded yet. Multiple instances of QPluginLoader can be used to access the same physical plugin.
Once loaded, plugins remain in memory until all instances of QPluginLoader has been unloaded, or until the application terminates. You can attempt to unload a plugin using unload(), but if other instances of QPluginLoader are using the same library, the call will fail, and unloading will only happen when every instance has called unload(). Right before the unloading happen, the root component will also be deleted.
In order to speed up loading and validation of plugins, some of the information that is collected during loading is cached in persistent memory (through QSettings). For instance, the result of a load operation (e.g. succeeded or failed) is stored in the cache, so that subsequent load operations don't try to load an invalid plugin. However, if the "last modified" timestamp of a plugin has changed, the plugin's cache entry is invalidated and the plugin is reloaded regardless of the values in the cache entry. The cache entry is then updated with the new result of the load operation.
This also means that the timestamp must be updated each time the plugin or any dependent resources (such as a shared library) is updated, since the dependent resources might influence the result of loading a plugin.
See How to Create Qt Plugins for more information about how to make your application extensible through plugins.
Note that the QPluginLoader cannot be used if your application is statically linked against Qt. In this case, you will also have to link to plugins statically. You can use QLibrary if you need to load dynamic libraries in a statically linked application.
Note: In Symbian the plugin stub files must be used whenever a path to plugin is needed. For the purposes of loading plugins, the stubs can be considered to have the same name as the actual plugin binary. In practice they have ".qtplugin" extension instead of ".dll", but this difference is handled transparently by QPluginLoader and QLibrary to avoid need for Symbian specific plugin handling in most Qt applications. Plugin stubs are needed because Symbian Platform Security denies all access to the directory where the actual plugin binaries are located.
The parent argument, if not None, causes self to be owned by Qt instead of PyQt.
Constructs a plugin loader with the given parent.
The parent argument, if not None, causes self to be owned by Qt instead of PyQt.
Constructs a plugin loader with the given parent that will load the plugin specified by fileName.
To be loadable, the file's suffix must be a valid suffix for a loadable library in accordance with the platform, e.g. .so on Unix, - .dylib on Mac OS X, and .dll on Windows. The suffix can be verified with QLibrary.isLibrary().
Note: In Symbian the fileName must point to plugin stub file.
See also setFileName().
Returns a text string with the description of the last error that occurred.
This function was introduced in Qt 4.2.
Returns the root component object of the plugin. The plugin is loaded if necessary. The function returns 0 if the plugin could not be loaded or if the root component object could not be instantiated.
If the root component object was destroyed, calling this function creates a new instance.
The root component, returned by this function, is not deleted when the QPluginLoader is destroyed. If you want to ensure that the root component is deleted, you should call unload() as soon you don't need to access the core component anymore. When the library is finally unloaded, the root component will automatically be deleted.
The component object is a QObject. Use qobject_cast() to access interfaces you are interested in.
See also load().
Returns true if the plugin is loaded; otherwise returns false.
See also load().
Loads the plugin and returns true if the plugin was loaded successfully; otherwise returns false. Since instance() always calls this function before resolving any symbols it is not necessary to call it explicitly. In some situations you might want the plugin loaded in advance, in which case you would use this function.
See also unload().
Returns a list of static plugin instances (root components) held by the plugin loader.
Unloads the plugin and returns true if the plugin could be unloaded; otherwise returns false.
This happens automatically on application termination, so you shouldn't normally need to call this function.
If other instances of QPluginLoader are using the same plugin, the call will fail, and unloading will only happen when every instance has called unload().
Don't try to delete the root component. Instead rely on that unload() will automatically delete it when needed.
See also instance() and load().
| PyQt 4.12.1 for X11 | Copyright © Riverbank Computing Ltd and The Qt Company 2015 | Qt 4.8.7 |