Core
This section contains a description of the SkydelCoreInterface supported by Skydel.
Runtime Logging
During simulation initialization, Skydel will create a temporary folder for every plug-in. Existing folders will be wiped. Plug-ins can access this path via the setLogPath
method. The path has the following format: Skydel Data Folder / Output / A / B where A is the configuration name and B the plug-in name.
Graphical User Interface
When enabling a plug-in, Skydel requests a SkydelWidgets
object via the createUI
method, which is a collection of SkydelWidget
instances. This allows a plug-in to integrate multiple widgets through the Skydel user interface and define a custom location for each of its widgets. When no path
and name
is specified, the default location of a widget will be under Settings / Plug-ins / B, where B is the plugin name. It is mandatory to fully transfer ownership of the widget pointer to Skydel.
widget
Contains the user interface widget
path
Location of the widget in the Skydel user interface supports two values: Settings
and Dock
. An exception is made for Settings
; in this case, sub-paths are supported (for example, Settings/MyPath
).
name
Name of the widget access to be displayed in the user interface
Notification
When enabling a plug-in, Skydel will create and give a SkydelNotifierInterface*
via the setNotifier
method. With this object, a plug-in can:
Send 3 different types of notifications to Skydel via the
notify
methodTell Skydel to change its state to Unsaved via the
setDirty
method
INFO
[Default] Message logged in simulator.log as an info
WARNING
Message logged in simulator.log and Skydel Status Log tab as a warning
ERROR
Message logged in simulator.log and Skydel Status Log tab as an error
Sending an ERROR
notification at runtime will cause the simulation to stop.
Configuration
When saving, Skydel will demand a QJsonObject
to every plug-in via the getConfiguration
method. The JSON object holds the current configuration of the plug-in, which will be saved in the Skydel configuration file and paired with the version of the plug-in it was generated with. The version saved in the Skydel configuration file comes from the plug-in metadata at save time.
When loading a configuration file, Skydel will automatically restore the configuration of the plug-in via the setConfiguration
method. It's possible for a plug-in to handle configuration backward compatibility since the configuration received is paired with a creation version.
Simulation Initialization
During the simulation initialization state, Skydel allows plug-ins to execute code before the simulation start via the initialize
method.
Example
See the plug-in example simple_plugin for more information. It covers:
Creating a user interface
Sending notification messages
Triggering the Unsaved state
Saving and loading of configuration
Last updated