This repository has been archived on 2026-05-31. You can view files and clone it, but cannot push or open issues or pull requests.
powersync-core/doc/getting-started-plugins.qdoc
2019-04-01 20:48:17 +02:00

185 lines
6.6 KiB
Plaintext

/*!
\page getting-started-plugins.html
\title Getting Started
In order to show how a plugin ist structured here is an example of the most minimalistic device plugin possible for the guh system.
\chapter Basic structure
The name of the plugin should be clear and inform about the content in one word. In this first minimalistic example the \b <pluginName> is \e "minimal".
The basic structure of the minimal plugin looks like this:
\code
$ ls -l minimal/
devicepluginminimal.cpp
devicepluginminimal.h
devicepluginminimal.json
minimal.pro
plugins.pri
\endcode
\section2 minimal.pro
The \tt minimal.pro file is the project file of the plugin, which can be openend with the \tt{Qt Creator}. The name of this file should be the same as the folder name of the project. In this example the name would be \e "minimal".
\code
include(plugins.pri)
TARGET = $$qtLibraryTarget(guh_devicepluginminimal)
message("Building $$deviceplugin$${TARGET}.so")
SOURCES += \
devicepluginminimal.cpp \
HEADERS += \
devicepluginminimal.h \
\endcode
The \b TARGET parameter definens the name of the resulting plugin lib file and should should have following name structure:
\tt {guh_deviceplugin\b<pluginName>}
In this example the pluginname is \e minimal, which means the lib file name will be \e guh_devicepluginminimal.so. You can check the name of the plugin in the "Project Messages" (\tt{alt + 6} in Qt Creator).
The \b SOURCES and \b HEADERS variables define the \tt .cpp and \tt .h files of your plugin like in any other Qt project.
\section2 plugins.pri
The \tt plugins.pri file contains all relevant definitions and configuration to build a plugin. Each plugin must contain this file and \underline{should not} be changed. In this file the precompiler \b guh-generateplugininfo will be called.
\code
TEMPLATE = lib
CONFIG += plugin
QT += network
QMAKE_CXXFLAGS += -Werror
CONFIG += c++11
INCLUDEPATH += /usr/include/guh
LIBS += -lguh
infofile.output = plugininfo.h
infofile.commands = /usr/bin/guh-generateplugininfo ${QMAKE_FILE_NAME} ${QMAKE_FILE_OUT}
infofile.depends = /usr/bin/guh-generateplugininfo
infofile.CONFIG = no_link
JSONFILES = deviceplugin"$$TARGET".json
infofile.input = JSONFILES
QMAKE_EXTRA_COMPILERS += infofile
target.path = /usr/lib/guh/plugins/
INSTALLS += target
\endcode
If you need an extra Qt module i.e. \tt serialport please add it in the \tt <pluginName>.pro file an not in the \tt plugin.pri:
\code
QT += serialport
\endcode
\section2 devicepluginminimal.json
The properties of a plugin will be definend with in the \tt JSON file containing all needed information for guh to load it. The name convention fot the json file is:
\tt {deviceplugin\b{<pluginName>}.json}
This file must have a clear, definend structure and looking like this:
\note For more details about the structure, values and Objects please take a look at the \l{The Plugin JSON File} documentation.
\code
{
"name": "Minimal plugin",
"idName": "Minimal",
"id": "6878754a-f27d-4007-a4e5-b030b55853f5",
"vendors": [
{
"name": "Minimal vendor",
"idName": "minimal",
"id": "3897e82e-7c48-4591-9a2f-0f56c55a96a4",
"deviceClasses": [
{
"deviceClassId": "7014e5f1-5b04-407a-a819-bbebd11fa372",
"idName": "minimal",
"name": "Minimal device",
"createMethods": ["user"],
"paramTypes": [
{
"name": "name",
"type": "QString",
"defaultValue": "Minimal device"
}
]
}
]
}
]
}
\endcode
In this minimal example of a device plugin we have one \l{Vendor} ("Minimal vendor") with the VendorId \tt {3897e82e-7c48-4591-9a2f-0f56c55a96a4}, which contains one \l{DeviceClass} with the name "Minimal device". The \l{DeviceClass} has one QString \l{Param} called \e name.
\section2 devicepluginminimal.h
The main header file of the plugin. The naming convention is:
\tt {deviceplugin\b<pluginName>.h}
In this file you can find the main class of the plugin: \e DevicePluginMinimal. As you can see the \e DevicePluginMinimal inherits from the class \l{DevicePlugin}. You can check out the \l{DevicePlugin} class description to find how a \l{DevicePlugin} looks like.
\code
#ifndef DEVICEPLUGINMINIMAL_H
#define DEVICEPLUGINMINIMAL_H
#include "plugin/deviceplugin.h"
#include "devicemanager.h"
class DevicePluginMinimal : public DevicePlugin
{
Q_OBJECT
Q_PLUGIN_METADATA(IID "guru.guh.DevicePlugin" FILE "devicepluginminimal.json")
Q_INTERFACES(DevicePlugin)
public:
explicit DevicePluginMinimal();
DeviceManager::HardwareResources requiredHardware() const override;
DeviceManager::DeviceSetupStatus setupDevice(Device *device) override;
};
#endif // DEVICEPLUGINBOBLIGHT_H
\endcode
As you can see this class has two methods which override the corresponding method in the \l{DevicePlugin} class. These two methods are pure virtual, which meas you \underline{must} implement them.
\section2 devicepluginminimal.cpp
The implementation of the \l{DevicePlugin}. The naming convention is:
\tt {deviceplugin\b<pluginName>.cpp}
\code
#include "devicepluginminimal.h"
#include "plugininfo.h"
DevicePluginMinimal::DevicePluginMinimal()
{
}
DeviceManager::HardwareResources DevicePluginMinimal::requiredHardware() const
{
return DeviceManager::HardwareResourceNone;
}
DeviceManager::DeviceSetupStatus DevicePluginMinimal::setupDevice(Device *device)
{
Q_UNUSED(device)
qCDebug(dcMinimal) << "setup device" << device->name() << device->id();
return DeviceManager::DeviceSetupStatusSuccess;
}
\endcode
*/