Plug-ins are the best way to add a specific set of features to the software without making changes to its core code. Based upon that, pgModeler has introduced a simple structure to provide a form to create third-party plug-ins. The first step in the development of a plug-in that handles pgModeler objects is to take a good reading on pgModeler's API as well as to the Qt plug-in system. You can generate the pgModeler's code documentation by using the
doxygen utility running the command
doxygen doxygen.conf at pgModeler's source code root. Once generated the code documentation is stored in the folder
docs under to source code directory. Details about configuring and installing doxygen application can be seen at its official website. Steps on how to retrieve the source code of pgModeler can be seen at the download page.
Once provided with the information you can start to create your own plug-ins. In the Qt framework, and consequently, in pgModeler, a plug-in is basically a C++ class implemented in a library installed in a path that is accessible by the application. Specifically, in pgModeler, the path of the plug-ins is configured using the
PGMODELER_PLUGIN_DIR environment variable (you can get details about environment variables used by the tool on the installation page.
Continuing to describe the development details, your C++ class that implements the plug-in must follow two basic rules: inherit the class
PgModelerPlugin overloading all its pure virtual methods and use the macros
Q_PLUGIN_METADATA in its declaration. Another rule is that the plug-ins in pgModeler must have a basic directory structure in order to be properly loaded when the application starts:
[PGMODELER_PLUGINS_DIR]/ | + - pluginA/ + - (lib)*(pluginA.)(so|dylib|dll) (library) + - pluginA.png (icon)
On the above schema, the directory named
pluginA is located on the root directory used by pgModeler to load plug-ins and stores all the assets and components of the extension. Inside the plug-in folder, there is the icon file that must be mandatorily named in the form
[plugin_name].png in this case
pluginA.png. In the same folder, we have the library that implements all the plug-in logic. The name of the library is platform dependent and can be:
pluginA.dll (Windows) and
Since the plug-in obviously needs to access the tool's features exposed by its classes, you'll need to compile the first one against the most recent pgModeler's source code. As a convenience, a basic plug-in implementation named dummy comes bundled with the source code. You can start to develop and compile your own extension by using that plug-in.
Note that pgModeler gives complete access to its classes and doesn't prohibit the plug-ins to read and write files outside their own paths, this way you must take extreme caution when developing a plug-in or even when installing an extension from suspicious sources since this may harm your computer or cause data loss.