Merge PR #178: Fix some typos

doc/generate-interfaces-qdoc.py

@@ -72,7 +72,7 @@ def loadInterfaces():
         if ".json" in fileName:
             interfaceFiles.append(interfacesDirectory + "/" + fileName)
 
-    # Sort file lists for beeing able to get the last n days logs
+    # Sort file lists for being able to get the last n days logs
     interfaceFiles.sort()
     for fileName in interfaceFiles:
         name = os.path.basename(fileName)

doc/jsonrpc-api.qdoc

@@ -1775,7 +1775,7 @@ Returns
 \endcode
 See also: \l{NetworkManagerError}
 \section2 Rules.AddRule
-Add a rule. You can describe rules by one or many EventDesciptors and a StateEvaluator. Note that only one of either eventDescriptor or eventDescriptorList may be passed at a time. A rule can be created but left disabled, meaning it won't actually be executed until set to enabled. If not given, enabled defaults to true. A rule can have a list of actions and exitActions. It must have at least one Action. For state based rules, actions will be executed when the system enters a state matching the stateDescriptor. The exitActions will be executed when the system leaves the described state again. For event based rules, actions will be executed when a matching event happens and if the stateEvaluator matches the system's state. ExitActions for such rules will be executed when a matching event happens and the stateEvaluator is not matching the system's state. A rule marked as executable can be executed via the API using Rules.ExecuteRule, that means, its actions will be executed regardless of the the eventDescriptor and stateEvaluators.
+Add a rule. You can describe rules by one or many EventDesciptors and a StateEvaluator. Note that only one of either eventDescriptor or eventDescriptorList may be passed at a time. A rule can be created but left disabled, meaning it won't actually be executed until set to enabled. If not given, enabled defaults to true. A rule can have a list of actions and exitActions. It must have at least one Action. For state based rules, actions will be executed when the system enters a state matching the stateDescriptor. The exitActions will be executed when the system leaves the described state again. For event based rules, actions will be executed when a matching event happens and if the stateEvaluator matches the system's state. ExitActions for such rules will be executed when a matching event happens and the stateEvaluator is not matching the system's state. A rule marked as executable can be executed via the API using Rules.ExecuteRule, that means, its actions will be executed regardless of the eventDescriptor and stateEvaluators.
 Params
 \code
 {
@@ -2967,7 +2967,7 @@ See also: \l{Tag}
             }
         }, 
         "Rules.AddRule": {
-            "description": "Add a rule. You can describe rules by one or many EventDesciptors and a StateEvaluator. Note that only one of either eventDescriptor or eventDescriptorList may be passed at a time. A rule can be created but left disabled, meaning it won't actually be executed until set to enabled. If not given, enabled defaults to true. A rule can have a list of actions and exitActions. It must have at least one Action. For state based rules, actions will be executed when the system enters a state matching the stateDescriptor. The exitActions will be executed when the system leaves the described state again. For event based rules, actions will be executed when a matching event happens and if the stateEvaluator matches the system's state. ExitActions for such rules will be executed when a matching event happens and the stateEvaluator is not matching the system's state. A rule marked as executable can be executed via the API using Rules.ExecuteRule, that means, its actions will be executed regardless of the the eventDescriptor and stateEvaluators.", 
+            "description": "Add a rule. You can describe rules by one or many EventDesciptors and a StateEvaluator. Note that only one of either eventDescriptor or eventDescriptorList may be passed at a time. A rule can be created but left disabled, meaning it won't actually be executed until set to enabled. If not given, enabled defaults to true. A rule can have a list of actions and exitActions. It must have at least one Action. For state based rules, actions will be executed when the system enters a state matching the stateDescriptor. The exitActions will be executed when the system leaves the described state again. For event based rules, actions will be executed when a matching event happens and if the stateEvaluator matches the system's state. ExitActions for such rules will be executed when a matching event happens and the stateEvaluator is not matching the system's state. A rule marked as executable can be executed via the API using Rules.ExecuteRule, that means, its actions will be executed regardless of the eventDescriptor and stateEvaluators.", 
             "params": {
                 "actions": [
                     "$ref:RuleAction"

doc/jsonrpc.qdoc

@@ -164,7 +164,7 @@
         \row
             \li \tt status
             \li string
-            \li Whether or not the JSONRPC request was successfull.
+            \li Whether or not the JSONRPC request was successful.
         \row
             \li \tt params
             \li json object

doc/plugin-json.qdoc

@@ -505,7 +505,7 @@ A \l{StateType} has following parameters:
             \li \tt possibleValues
             \li \b O
             \li array
-            \li Gives you the possibility to define a list of possible values which this state can have. This allowes a user to create a rule based
+            \li Gives you the possibility to define a list of possible values which this state can have. This allows a user to create a rule based
                 on a state and define only values which are possible. This is typically used for strings i.e. \tt {["Loading", "Installing", "Removing"]}.
         \row
             \li \tt writable

doc/tutorials/plugin-wizard.qdoc

@@ -69,7 +69,7 @@
         \image plugin-template-5.png Kit selection
 
     \section2 Project Management
-        Here you can select your prefered project management tool. If you choose git,
+        Here you can select your preferred project management tool. If you choose git,
         the default \tt{.gitignore} file will be added to the project.
 
         \image plugin-template-6.png Project Management
@@ -94,7 +94,7 @@
         \list
 
             \li In the first line you can see the gloabl nymea plugin include, where all the nymea plugin related
-                configrations and setting for your plugin project get included.
+                configurations and setting for your plugin project get included.
                 \printline include(
 
             \li The next line defines the library file name of your plugin. If you change the plugin name, this line has to be updated to.
@@ -177,7 +177,7 @@
 
     As you can see, the plugin includes in the cpp file the \tt{plugininfo.h} file, which will be generated during build time
     from the \tt{nymea-generateplugininfo} tool. This tool translates the \l{deviceplugintemplate.json} into a c++ header file
-    containing all uuid definitions, tranlations strings and the debug catergory definition.
+    containing all uuid definitions, translations strings and the debug catergory definition.
 
     \quotefromfile template/deviceplugintemplate.cpp
     \skipto #include
@@ -201,7 +201,7 @@
     \printuntil }
 
     The \l{DevicePlugin::deviceRemoved()}{deviceRemoved} method will be called from the DeviceManager once a device is about to be removed from the system.
-    Here is a good place to clean up everything releated to the device which will be removed.
+    Here is a good place to clean up everything related to the device which will be removed.
     \skipto deviceRemoved
     \printuntil }
 

doc/tutorials/your-first-plugin.qdoc

@@ -108,7 +108,7 @@
 
     The server will verify if the required types for an interface match the template. This will be evaluated once the server loads the plugin.
 
-    Once you updated the JSON file, you have to rebuild the whole plugin in order to trigger a rebuild of the the plugin information
+    Once you updated the JSON file, you have to rebuild the whole plugin in order to trigger a rebuild of the plugin information
     include files.
 
     \section2 nymea-generateplugininfo
@@ -145,14 +145,14 @@
 
     And finally, once the action \tt press gets called, the event \tt pressed will be emitted in the system.
 
-    This event can be connected whithin a rule to execute whatever action you want.
+    This event can be connected within a rule to execute whatever action you want.
 
     \section1 Test the plugin
 
     Now it's time to build you first plugin. In order to make sure all changes in you JSON file are up to date press the \tt{Rebuild all} instead
     of only \tt {Build}. This will rerun the nymea-generateplugininfo tool and update the \tt plugininfo.h and \tt extern-plugininfo.h files.
 
-    \note Comming soon!
+    \note Coming soon!
 
 
 */

libnymea-core/debugserverhandler.cpp

@@ -1612,7 +1612,7 @@ QByteArray DebugServerHandler::createDebugXmlDocument()
     writer.writeTextElement("h2", tr("Server live logs"));
     writer.writeEmptyElement("hr");
 
-    writer.writeTextElement("p", tr("This section allowes you to see the live logs of the nymea server."));
+    writer.writeTextElement("p", tr("This section allows you to see the live logs of the nymea server."));
 
     // Toggle log button
     writer.writeStartElement("button");

libnymea-core/jsonrpc/jsonrpcserver.cpp

@@ -643,7 +643,7 @@ void JsonRPCServer::processJsonPacket(TransportInterface *interface, const QUuid
         }
 
 
-        // Unless this is the Hello message, which allows setting the locale explicity, attach the locale
+        // Unless this is the Hello message, which allows setting the locale explicitly, attach the locale
         // for this connection
         // If the client did request a locale in the Hello message, use that locale
         params.insert("locale", m_clientLocales.value(clientId));

libnymea-core/jsonrpc/ruleshandler.cpp

@@ -94,7 +94,7 @@ RulesHandler::RulesHandler(QObject *parent) :
                               "happens and if the stateEvaluator matches the system's state. ExitActions for such rules will be "
                               "executed when a matching event happens and the stateEvaluator is not matching the system's state. "
                               "A rule marked as executable can be executed via the API using Rules.ExecuteRule, that means, its "
-                              "actions will be executed regardless of the the eventDescriptor and stateEvaluators.");
+                              "actions will be executed regardless of the eventDescriptor and stateEvaluators.");
     params.insert("name", JsonTypes::basicTypeToString(JsonTypes::String));
     params.insert("actions", QVariantList() << JsonTypes::ruleActionRef());
     params.insert("o:timeDescriptor", JsonTypes::timeDescriptorRef());

libnymea-core/servers/bluetoothserver.cpp

@@ -134,7 +134,7 @@ void BluetoothServer::onClientDisconnected()
 
 void BluetoothServer::onClientError(QBluetoothSocket::SocketError error)
 {
-    qCWarning(dcBluetoothServer()) << "BluetoothServer: Error occured:" << error;
+    qCWarning(dcBluetoothServer()) << "BluetoothServer: Error occurred:" << error;
 }
 
 void BluetoothServer::onClientStateChanged(QBluetoothSocket::SocketState state)

libnymea-core/usermanager.cpp

@@ -36,7 +36,7 @@
     This enum represents the possible errors the \l{UserManager} can have.
 
     \value UserErrorNoError
-        No error occured. Everything is ok.4
+        No error occurred. Everything is ok.4
     \value UserErrorBackendError
         Something went wrong in the manager. This is probably caused by a database error.
     \value UserErrorInvalidUserId
@@ -197,7 +197,7 @@ bool UserManager::pushButtonAuthAvailable() const
 }
 
 /*! Authenticated the given \a username with the given \a password for the \a deviceName. If the authentication was
-    successfull, the token will be returned, otherwise the return value will be an empty byte array.
+    successful, the token will be returned, otherwise the return value will be an empty byte array.
 */
 QByteArray UserManager::authenticate(const QString &username, const QString &password, const QString &deviceName)
 {

libnymea/hardware/bluetoothlowenergy/bluetoothdiscoveryreply.cpp

@@ -38,7 +38,7 @@
     This enum represents the possible errors of a BluetoothDiscoveryReply.
 
     \value BluetoothDiscoveryReplyErrorNoError
-        No error occured. Everything is fine.
+        No error occurred. Everything is fine.
     \value BluetoothDiscoveryReplyErrorNotAvailable
         The discovery could not be performed because there is no Bluetooth hardware available.
     \value BluetoothDiscoveryReplyErrorNotEnabled
@@ -62,7 +62,7 @@
 */
 
 /*! \fn void BluetoothDiscoveryReply::errorOccurred(const BluetoothDiscoveryReplyError &error);
-    This signal will be emitted whenever an \a error occured.
+    This signal will be emitted whenever an \a error occurred.
 
     \sa error, BluetoothDiscoveryReplyError
 */

libnymea/hardware/bluetoothlowenergy/bluetoothlowenergydevice.cpp

@@ -112,7 +112,7 @@
 */
 
 /*! \fn void BluetoothLowEnergyDevice::errorOccurred(const QLowEnergyController::Error &error);
-    This signal will be emitted whenever an \a error occured.
+    This signal will be emitted whenever an \a error occurred.
 */
 
 /*! \fn void BluetoothLowEnergyDevice::servicesDiscoveryFinished();

libnymea/hardware/bluetoothlowenergy/bluetoothlowenergymanager.cpp

@@ -58,7 +58,7 @@ BluetoothLowEnergyManager::BluetoothLowEnergyManager(QObject *parent) :
 {
 }
 
-/*! This method enables / disables this hardwareresource for all plugins. This method is available on the D-Bus. This can be usefull if a Bluetooth LE server
+/*! This method enables / disables this hardwareresource for all plugins. This method is available on the D-Bus. This can be useful if a Bluetooth LE server
     needs access to the hardware. By disabling the bluetooth support, nymea will not allow to use the hardware until it gets reenabled.
 */
 void BluetoothLowEnergyManager::EnableBluetooth(bool enabled)

libnymea/hardwaremanager.cpp

@@ -72,7 +72,7 @@ HardwareManager::HardwareManager(QObject *parent) :
 
 }
 
-/*! Sets the given \a resource to \a enabled. This allowes to enable/disable individual \l{HardwareResource}{HardwareResources}. */
+/*! Sets the given \a resource to \a enabled. This allows to enable/disable individual \l{HardwareResource}{HardwareResources}. */
 void HardwareManager::setResourceEnabled(HardwareResource *resource, bool enabled)
 {
     resource->setEnabled(enabled);

libnymea/network/mqtt/mqttprovider.cpp

@@ -31,7 +31,7 @@
     For one it supports establishing a secure channel between the device and the plugin, using nymea's internal MQTT
     broker. The second approach is to provide a generic MQTT client object connected to nymea's internal MQTT broker.
 
-    Note, if you whish to establish a MQTT connection to an external MQTT broker, you can just create your own MqttClient
+    Note, if you wish to establish a MQTT connection to an external MQTT broker, you can just create your own MqttClient
     and connect to wherever you need to. The MqttProvider hardware resource only manages connections to the nymea internal
     MQTT broker.
 

libnymea/plugintimer.cpp

@@ -27,7 +27,7 @@
     \ingroup hardware
     \inmodule libguh
 
-    The plugin timer allowes to trigger repeating actions in a device plugin. This timer does not represent a precise timer
+    The plugin timer allows to trigger repeating actions in a device plugin. This timer does not represent a precise timer
     should be used for not time critical things. The PluginTimerManager will schedule the requested timer as needed and
     trigger the timeout() method.
 

tests/auto/api.json

@@ -735,7 +735,7 @@
             }
         },
         "Rules.AddRule": {
-            "description": "Add a rule. You can describe rules by one or many EventDesciptors and a StateEvaluator. Note that only one of either eventDescriptor or eventDescriptorList may be passed at a time. A rule can be created but left disabled, meaning it won't actually be executed until set to enabled. If not given, enabled defaults to true. A rule can have a list of actions and exitActions. It must have at least one Action. For state based rules, actions will be executed when the system enters a state matching the stateDescriptor. The exitActions will be executed when the system leaves the described state again. For event based rules, actions will be executed when a matching event happens and if the stateEvaluator matches the system's state. ExitActions for such rules will be executed when a matching event happens and the stateEvaluator is not matching the system's state. A rule marked as executable can be executed via the API using Rules.ExecuteRule, that means, its actions will be executed regardless of the the eventDescriptor and stateEvaluators.",
+            "description": "Add a rule. You can describe rules by one or many EventDesciptors and a StateEvaluator. Note that only one of either eventDescriptor or eventDescriptorList may be passed at a time. A rule can be created but left disabled, meaning it won't actually be executed until set to enabled. If not given, enabled defaults to true. A rule can have a list of actions and exitActions. It must have at least one Action. For state based rules, actions will be executed when the system enters a state matching the stateDescriptor. The exitActions will be executed when the system leaves the described state again. For event based rules, actions will be executed when a matching event happens and if the stateEvaluator matches the system's state. ExitActions for such rules will be executed when a matching event happens and the stateEvaluator is not matching the system's state. A rule marked as executable can be executed via the API using Rules.ExecuteRule, that means, its actions will be executed regardless of the eventDescriptor and stateEvaluators.",
             "params": {
                 "actions": [
                     "$ref:RuleAction"