qt creator of all aspects of the source code analysis (2-10-4)

Plugin Life Cycle

In order to be able to write Qt Creator plug-in, you must understand when you start or shut down Qt Creator, the steps taken by the Plugin Manager. Plug-experienced process and conditions described in detail in this section.

Before starting the Qt Creator, set environment variables QT_LOGGING_RULES为qtc.extensionsystem*=true, you can enable plug-ins associated with the debug log output, after the start, you can get more information about the situation.

When start Qt Creator, the Plugin Manager does the following:

1. Find all dynamic objects in its search path, and read library metadata. All metadata and IID is not no org.qt-project.Qt.QtCreatorPluginlibrary will be ignored. This is the first place where load plugins may fail, in the worst case metadata format errors.

2. Created for each plug-in ExtensionSystem :: PluginSpec instance of the class. Such a container is, contains all of the information from the plug-in specifications, and also the status of the plug. You can () function, or the plug-in is loaded () function to get through pluginSpec plug through plugins Plug-In Manager ExtensionSystem :: PluginSpec instance.

3. The plug-in settings for the Readstate.

4. Each dependency validation plugin exists and is compatible. For more information about plug-in dependencies, see Plugin Meta the Data .

5. The plug-in settings for the Resolvedstate.

6. Will sort all plug-ins to the list, we call the load queue , the queue, dependent plug-ins are located behind the plug-in (but not necessarily immediately adjacent to the plug-in after). This will ensure that we load in the correct order and initialize the plug.

7. Loading plug-in library, and create IPlugin instance in the order corresponding to the load queue. At this time, the constructor is called plug-ins. Being dependent on other plug-ins to create.

8. The plug-in settings for the Loadedstate.

9. Call each widget initialize () functions in the order of the load queue. In the initialization function, the plug should ensure that all export interface have been set up, and other plug-ins available for use. Export interface plug-in can assume they rely on plug-ins have been set up. For example, Coreplug-ins are provided Core::ActionManager，Core::EditorManagerand all other public interfaces are available, and therefore requests and other plug-ins can use them.

   Plug-in initialize () function For Here is a good place:

   • Registered object in the object pool Plugin Manager (see at The Plugin Manager, at The Object Pool, and Registered Objects )
   • Loading Configuration
   • Add new menus and menu operation
   • Signal is connected to the other plugins

10. The plug-in settings for the Initializedstate.

11. To load the queue of calls all plugins reverse order extensionsInitialized () function. After extensionsInitialized function, plug-in should be thoroughly completed initialization, set up and run. It can be assumed dependent on the plug insert also has been completely set up, and may be part of the initialization is completed for other plug-in extensions. For example, Coreplug-in plug-ins can be assumed that all its actions have been registered, and finish initializing operation manager.

12. The plug-in settings for the Runningstate.

At the end of starting, Coreplug-Core :: ICore send two signals. Before Qt Creator UI display, it first sends coreAboutToOpen (), and then transmits coreOpened ().

After the start, Qt Creator of the event loop running, plug-in manager will call delayedInitialize all plug-ins () function in the reverse order to load the queue. The call is complete on the main thread, but separated by a few milliseconds of delay, to ensure that Qt Creator responsiveness. In delayInitialize function, plug-ins can perform non-critical initialization, if during the startup process, may unnecessarily delay the display of Qt Creator UI's.

After completion of the initialization of all delays, the PluginManager sends initializeDone () signal.

Before closing, Coreplug-Core :: ICore send coreAboutToClose () signal. After that, the plug-in manager to start an orderly shutdown:

1. In order to load the queue, call all plug-ins aboutToShutdown () function. Plug-in here should implement measures to speed up the actual closing speed, for example, the signal would have been no need to call disconnected. If the plugin needs to delay the actual close period of time, for example, if you need to wait for an external process to complete a clean exit from the plug-in function returns ExtensionSystem :: IPlugin :: AsynchronousShutdown. This will enable plug-in manager waits for the next step, and keep the main event loop to run until all requests AsynchronousShutdown plugins sent asynchronousShutdownFinished until the signal ().
2. In reverse order of the load queue, remove the plug of ExtensionSystem :: IPlugin instance, to destroy all plug-ins. In this case, the plugin calls the destructor. After the release of memory and other resources to clean up their own plug-ins.