# Core

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

```cpp
SkydelWidgets B::createUI()
{
    auto* ui = new QWidget{};

    // connect signal/slots

    return {{ui, "Settings", "B"}};
}
```

<table><thead><tr><th width="166">SkydelWidget</th><th>Description</th></tr></thead><tbody><tr><td>widget</td><td>Contains the user interface widget</td></tr><tr><td>path</td><td>Location of the widget in the Skydel user interface supports two values: <code>Settings</code> and <code>Dock</code>. An exception is made for <code>Settings</code>; in this case, sub-paths are supported (for example, <code>Settings/MyPath</code>).</td></tr><tr><td>name</td><td>Name of the widget access to be displayed in the user interface</td></tr></tbody></table>

## 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` method
* Tell Skydel to change its state to Unsaved via the `setDirty` method

<table data-full-width="false"><thead><tr><th width="146" align="center">Type</th><th>Description</th></tr></thead><tbody><tr><td align="center"><code>INFO</code></td><td>[Default] Message logged in <em>simulator.log as</em> an <em>info</em></td></tr><tr><td align="center"><code>WARNING</code></td><td>Message logged in <em>simulator.log</em> and Skydel <em>Status Log</em> tab as a <em>warning</em></td></tr><tr><td align="center"><code>ERROR</code></td><td>Message logged in <em>simulator.log and</em> Skydel <em>Status Log</em> tab as an <em>error</em></td></tr></tbody></table>

Sending an `ERROR` notification at runtime will cause the simulation to stop.

```cpp
void B::setNotifier(SkydelNotifierInterface* notifier)
{
    // Sends an warning message to Skydel
    notifier->notify("Hello", SkydelNotifierInterface::Type::WARNING);

    // Tells Skydel to change it' state to unsaved
    notifier->setDirty();
}
```

## 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 starts via the `initialize` method.

Remote API clients cannot execute commands during Skydel's initialization state, but an exception is made for plug-ins within the initialize method. Although the simulator is technically in the *Started* state, Skydel allows plug-ins to execute *Idle* commands.

## Example

See the plug-in example [simple\_plugin](https://github.com/learn-safran-navigation-timing/skydel-example-plugins/tree/master/source/simple_plugin) for more information. It covers:

* Creating a user interface
* Sending notification messages
* Triggering the Unsaved state
* Saving and loading of configuration


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://skydel.gitbook.io/skydel-plug-ins-documentation/plug-in-development/roles/core.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.