From 5ed3e73974ca464a46ec4158c44330d664ab4820 Mon Sep 17 00:00:00 2001 From: Michael Zanetti Date: Fri, 21 Jun 2019 01:07:07 +0200 Subject: [PATCH] Fix some typos --- doc/generate-interfaces-qdoc.py | 2 +- doc/jsonrpc-api.qdoc | 4 ++-- doc/jsonrpc.qdoc | 2 +- doc/plugin-json.qdoc | 2 +- doc/tutorials/plugin-wizard.qdoc | 8 ++++---- doc/tutorials/your-first-plugin.qdoc | 6 +++--- libnymea-core/debugserverhandler.cpp | 2 +- libnymea-core/jsonrpc/jsonrpcserver.cpp | 2 +- libnymea-core/jsonrpc/ruleshandler.cpp | 2 +- libnymea-core/servers/bluetoothserver.cpp | 2 +- libnymea-core/usermanager.cpp | 4 ++-- .../bluetoothlowenergy/bluetoothdiscoveryreply.cpp | 4 ++-- .../bluetoothlowenergy/bluetoothlowenergydevice.cpp | 2 +- .../bluetoothlowenergy/bluetoothlowenergymanager.cpp | 2 +- libnymea/hardwaremanager.cpp | 2 +- libnymea/network/mqtt/mqttprovider.cpp | 2 +- libnymea/plugintimer.cpp | 2 +- tests/auto/api.json | 2 +- 18 files changed, 26 insertions(+), 26 deletions(-) diff --git a/doc/generate-interfaces-qdoc.py b/doc/generate-interfaces-qdoc.py index 625d1b57..7257334e 100755 --- a/doc/generate-interfaces-qdoc.py +++ b/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) diff --git a/doc/jsonrpc-api.qdoc b/doc/jsonrpc-api.qdoc index 23b2abad..b6370686 100644 --- a/doc/jsonrpc-api.qdoc +++ b/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" diff --git a/doc/jsonrpc.qdoc b/doc/jsonrpc.qdoc index 02c4421e..061a914f 100644 --- a/doc/jsonrpc.qdoc +++ b/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 diff --git a/doc/plugin-json.qdoc b/doc/plugin-json.qdoc index 4dc9eec2..0e12a774 100644 --- a/doc/plugin-json.qdoc +++ b/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 diff --git a/doc/tutorials/plugin-wizard.qdoc b/doc/tutorials/plugin-wizard.qdoc index 81b7f26d..00970f52 100644 --- a/doc/tutorials/plugin-wizard.qdoc +++ b/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 } diff --git a/doc/tutorials/your-first-plugin.qdoc b/doc/tutorials/your-first-plugin.qdoc index fe854444..04f6d0a6 100644 --- a/doc/tutorials/your-first-plugin.qdoc +++ b/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! */ diff --git a/libnymea-core/debugserverhandler.cpp b/libnymea-core/debugserverhandler.cpp index bb27c2b1..77a357ef 100644 --- a/libnymea-core/debugserverhandler.cpp +++ b/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"); diff --git a/libnymea-core/jsonrpc/jsonrpcserver.cpp b/libnymea-core/jsonrpc/jsonrpcserver.cpp index 1bea5280..d0a73216 100644 --- a/libnymea-core/jsonrpc/jsonrpcserver.cpp +++ b/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)); diff --git a/libnymea-core/jsonrpc/ruleshandler.cpp b/libnymea-core/jsonrpc/ruleshandler.cpp index bae4b307..3ef7ff61 100644 --- a/libnymea-core/jsonrpc/ruleshandler.cpp +++ b/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()); diff --git a/libnymea-core/servers/bluetoothserver.cpp b/libnymea-core/servers/bluetoothserver.cpp index 0464ead7..1adc3da9 100644 --- a/libnymea-core/servers/bluetoothserver.cpp +++ b/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) diff --git a/libnymea-core/usermanager.cpp b/libnymea-core/usermanager.cpp index ef1c6a85..d593ef8e 100644 --- a/libnymea-core/usermanager.cpp +++ b/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) { diff --git a/libnymea/hardware/bluetoothlowenergy/bluetoothdiscoveryreply.cpp b/libnymea/hardware/bluetoothlowenergy/bluetoothdiscoveryreply.cpp index b699bddc..d18b15a0 100644 --- a/libnymea/hardware/bluetoothlowenergy/bluetoothdiscoveryreply.cpp +++ b/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 */ diff --git a/libnymea/hardware/bluetoothlowenergy/bluetoothlowenergydevice.cpp b/libnymea/hardware/bluetoothlowenergy/bluetoothlowenergydevice.cpp index 190c0aa0..0484fa81 100644 --- a/libnymea/hardware/bluetoothlowenergy/bluetoothlowenergydevice.cpp +++ b/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(); diff --git a/libnymea/hardware/bluetoothlowenergy/bluetoothlowenergymanager.cpp b/libnymea/hardware/bluetoothlowenergy/bluetoothlowenergymanager.cpp index 6776dc7f..81c38b37 100644 --- a/libnymea/hardware/bluetoothlowenergy/bluetoothlowenergymanager.cpp +++ b/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) diff --git a/libnymea/hardwaremanager.cpp b/libnymea/hardwaremanager.cpp index a6a635c9..21f9e3dd 100644 --- a/libnymea/hardwaremanager.cpp +++ b/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); diff --git a/libnymea/network/mqtt/mqttprovider.cpp b/libnymea/network/mqtt/mqttprovider.cpp index 57ac2e5e..ffd07bc3 100644 --- a/libnymea/network/mqtt/mqttprovider.cpp +++ b/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. diff --git a/libnymea/plugintimer.cpp b/libnymea/plugintimer.cpp index 3695e109..3b85ca0e 100644 --- a/libnymea/plugintimer.cpp +++ b/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. diff --git a/tests/auto/api.json b/tests/auto/api.json index 1a8639c6..6211ef97 100644 --- a/tests/auto/api.json +++ b/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"