ETM-Schurig
/
nymea
mirror of https://github.com/nymea/nymea.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge PR #178: Fix some typos

pull/174/head
Jenkins 2019-06-28 12:45:37 +02:00
parent c07734621c 5ed3e73974
commit a7e6e80941
18 changed files with 26 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/generate-interfaces-qdoc.py
View File

@ -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)

4
doc/jsonrpc-api.qdoc
View File

@ -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"

2
doc/jsonrpc.qdoc
View File

@ -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

2
doc/plugin-json.qdoc
View File

@ -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

8
doc/tutorials/plugin-wizard.qdoc
View File

@ -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 }

6
doc/tutorials/your-first-plugin.qdoc
View File

@ -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!
*/

2
libnymea-core/debugserverhandler.cpp
View File

@ -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");

2
libnymea-core/jsonrpc/jsonrpcserver.cpp
View File

@ -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));

2
libnymea-core/jsonrpc/ruleshandler.cpp
View File

@ -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());

2
libnymea-core/servers/bluetoothserver.cpp
View File

@ -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)

4
libnymea-core/usermanager.cpp
View File

@ -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)
{

4
libnymea/hardware/bluetoothlowenergy/bluetoothdiscoveryreply.cpp
View File

@ -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
*/

2
libnymea/hardware/bluetoothlowenergy/bluetoothlowenergydevice.cpp
View File

@ -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();

2
libnymea/hardware/bluetoothlowenergy/bluetoothlowenergymanager.cpp
View File

@ -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)

2
libnymea/hardwaremanager.cpp
View File

@ -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);

2
libnymea/network/mqtt/mqttprovider.cpp
View File

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

2
libnymea/plugintimer.cpp
View File

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

2
tests/auto/api.json
View File

@ -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"