Extending Qt Creator Manual | IPlugin

Extending Qt Creator Manual 4.6.0

# IPlugin Class

(ExtensionSystem::IPlugin)

The IPlugin class is the base class for all plugins. More...

Header: | #include <IPlugin>
Inherited By: | ProjectExplorer::ProjectExplorerPlugin and VcsBase::VcsBasePlugin

- List of all members, including inherited members

## Public Types

enum | ShutdownFlag { SynchronousShutdown, AsynchronousShutdown }

## Public Functions

virtual ShutdownFlag | aboutToShutdown()
void | addAutoReleasedObject(QObject *obj)
void | addObject(QObject *obj)
virtual QList<QObject *> | createTestObjects() const
virtual bool | delayedInitialize()
virtual void | extensionsInitialized() = 0
virtual bool | initialize(const QStringList &arguments, QString *errorString) = 0
PluginSpec * | pluginSpec() const
virtual QObject * | remoteCommand(const QStringList &options, const QString &workingDirectory, const QStringList &arguments)
void | removeObject(QObject *obj)

## Signals

void | asynchronousShutdownFinished()

## Detailed Description

The IPlugin class is the base class for all plugins.

The IPlugin class is an abstract class that must be implemented once for each plugin. A plugin consists of two parts: A description file, and a library that at least contains the IPlugin implementation.

### Plugin Specification

A plugin needs to provide a plugin specification file in addition to the actual plugin library, so the plugin manager can find the plugin, resolve its dependencies, and load it. For more information, see Plugin Specifications.

### Plugin Implementation

Plugins must provide one implementation of the IPlugin class, located in a library that matches the `name` attribute given in their XML description. The IPlugin implementation must be exported and made known to Qt's plugin system, using the `Q_PLUGIN_METADATA` macro with an IID set to `"org.qt-project.Qt.QtCreatorPlugin"`.

After the plugins' XML files have been read, and dependencies have been found, the plugin loading is done in three phases:

1. All plugin libraries are loaded in root-to-leaf order of the dependency tree.
2. All plugins' initialize functions are called in root-to-leaf order of the dependency tree. This is a good place to put objects in the plugin manager's object pool.
3. All plugins' extensionsInitialized functions are called in leaf-to-root order of the dependency tree. At this point, plugins can be sure that all plugins that depend on this plugin have been initialized completely (implying that they have put objects in the object pool, if they want that during the initialization sequence).

If library loading or initialization of a plugin fails, all plugins that depend on that plugin also fail.

Plugins have access to the plugin manager (and its object pool) via the PluginManager::instance() function.

## Member Type Documentation

### enum IPlugin::ShutdownFlag

## Member Function Documentation

### `[virtual]` ShutdownFlag IPlugin::aboutToShutdown()

Called during a shutdown sequence in the same order as initialization before the plugins get deleted in reverse order.

This function should be used to disconnect from other plugins, hide all UI, and optimize shutdown in general. If a plugin needs to delay the real shutdown for a while, for example if it needs to wait for external processes to finish for a clean shutdown, the plugin can return IPlugin::AsynchronousShutdown from this function. This will keep the main event loop running after the aboutToShutdown() sequence has finished, until all plugins requesting AsynchronousShutdown have sent the asynchronousShutdownFinished() signal.

The default implementation of this function does nothing and returns IPlugin::SynchronousShutdown.

Returns IPlugin::AsynchronousShutdown if the plugin needs to perform asynchronous actions before performing the shutdown.

See also asynchronousShutdownFinished().

### void IPlugin::addAutoReleasedObject(QObject *obj)

Convenience function for registering obj in the plugin manager's plugin pool. Usually, registered objects must be removed from the object pool and deleted by hand. Objects added to the pool via addAutoReleasedObject are automatically removed and deleted in reverse order of registration when the IPlugin instance is destroyed.

See also PluginManager::addObject().

### void IPlugin::addObject(QObject *obj)

Convenience function that registers obj in the plugin manager's plugin pool by just calling PluginManager::addObject().

### `[signal]` void IPlugin::asynchronousShutdownFinished()

Sent by the plugin implementation after a asynchronous shutdown is ready to proceed with the shutdown sequence.

See also aboutToShutdown().

### `[virtual]` QList<QObject *> IPlugin::createTestObjects() const

Returns objects that are meant to be passed on to QTest::qExec().

This function will be called if the user starts Qt Creator with '-test PluginName' or '-test all'.

The ownership of returned objects is transferred to caller.

### `[virtual]` bool IPlugin::delayedInitialize()

Called after all plugins' IPlugin::extensionsInitialized() function has been called, and after the IPlugin::delayedInitialize() function of plugins that depend on this plugin have been called.

The plugins' delayedInitialize() functions are called after the application is already running, with a few milliseconds delay to application startup, and between individual delayedInitialize function calls. To avoid unnecessary delays, a plugin should return true from the function if it actually implements it, to indicate that the next plugins' delayedInitialize() call should be delayed a few milliseconds to give input and paint events a chance to be processed.

This function can be used if a plugin needs to do non-trivial setup that doesn't necessarily need to be done directly at startup, but still should be done within a short time afterwards. This can decrease the felt plugin/application startup time a lot, with very little effort.

See also initialize() and extensionsInitialized().

### `[pure virtual]` void IPlugin::extensionsInitialized()

Called after the IPlugin::initialize() function has been called, and after both the IPlugin::initialize() and IPlugin::extensionsInitialized() functions of plugins that depend on this plugin have been called.

In this function, the plugin can assume that plugins that depend on this plugin are fully 'up and running'. It is a good place to look in the plugin manager's object pool for objects that have been provided by dependent plugins.

See also initialize() and delayedInitialize().

### `[pure virtual]` bool IPlugin::initialize(const QStringList &arguments, QString *errorString)

Called after the plugin has been loaded and the IPlugin instance has been created.

The initialize functions of plugins that depend on this plugin are called after the initialize function of this plugin has been called. Plugins should initialize their internal state in this function. Returns if initialization of successful. If it wasn't successful, the errorString should be set to a user-readable message describing the reason.

See also extensionsInitialized() and delayedInitialize().

### PluginSpec *IPlugin::pluginSpec() const

Returns the PluginSpec corresponding to this plugin. This is not available in the constructor.

### `[virtual]` QObject *IPlugin::remoteCommand(const QStringList &options, const QString &workingDirectory, const QStringList &arguments)

### void IPlugin::removeObject(QObject *obj)

Convenience function that unregisters obj from the plugin manager's plugin pool by just calling PluginManager::removeObject().