Plugin Development Overview

The plugin documentation is focused around maintaining existing plugins. The recommended way to create a new plugin is to use an existing plugin as starting point and modify it in steps rather than to start from scratch.

The plugin API describes how a plugin interacts with the OpenCPN core. It is described in the API Page.

OpenCPN is a cross-platform project, and basically every plugin is compiled for different platforms. The core OpenCPN evaluates a plugin’s ABI compatibility in a rather strict way as described in the ABI compatibility page. There is also some notes on the ABI in the API Page.

Plugins should take special steps if depending on libraries besides those used by the core OpenCPN. More info on this in Dependencies

Since 5.4.0 the plugin installer is the main deployment method. An overview can be found here. The reference documentation is in the Plugin Installer Site. Plugins deployed this way are available for user to install in the OpenCPN GUI.

In this scheme, plugins are distributed as archives basically containing a metadata description, a dynamic library, data files and translations. The installer defines the layout of the archive and how these files are installed on the client’s computer. The exact paths involved are described in the Tarball layout page.

Plugins which need to save configuration and other data uses the configuration directory which is described in the Terminology page.

Historically, plugins have been distributed as operating system packages. All plugins today supports this on at least some platform(s). Some notes on this packaging can be found in the Legacy Plugins Page.

For a plugin to be available for end users, it must be included in the catalog. The catalog as well as tooling and processes to maintain it is governed by the catalog project at github.

The PI deployment scheme utilizes a number of services to build and distribute plugins. There are two sets of templates available:

The deployment for basically all existing plugins is using one of these two sets of templates.

Core OpenCPN and plugins shares a common translation process based on the gettext tools and the crowdin service. The process is described in the i18n Page

Hand-on info on creating plugin documentation can be found in the Plugin Manual