Plug-ins are the best way to add a specific set of features to a software without make 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 its to take a good reading on pgModeler's API as well 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 docsunder to source code directory. Details about configuring and installing doxygen application can ge seen at the its official web site. Steps on how to retrieve the source code of pgModeler can be seen at the download page.

Once provided with information you can start to create your own plug-ins. In 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 plug-ins path 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_INTERFACES and 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 are 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's logic. The name of the library is platform dependent and can be: libpluginA.so (Linux), pluginA.dll (Windows) and libpluginA.dylib (macOS).

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 prohibits 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.