summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/agent-api.txt8
-rw-r--r--doc/backtrace.txt2
-rw-r--r--doc/counter-api.txt2
-rw-r--r--doc/ipconfig-api.txt2
-rw-r--r--doc/overview-api.txt22
-rw-r--r--doc/plugin-api.txt2
-rw-r--r--doc/service-api.txt4
7 files changed, 21 insertions, 21 deletions
diff --git a/doc/agent-api.txt b/doc/agent-api.txt
index d215b9be..b4b8a39d 100644
--- a/doc/agent-api.txt
+++ b/doc/agent-api.txt
@@ -31,8 +31,8 @@ Methods void Release()
The return value should be a dictionary where the
keys are the field names and the values are the
- actual fields. Alternative an error indicating that
- the request got cannceled can be returned.
+ actual fields. Alternatively an error indicating that
+ the request got canceled can be returned.
Most common return field names are "Name" and of
course "Passphrase".
@@ -76,8 +76,8 @@ Arguments string Type
Contains the requirement option. Valid values are
"mandatory", "optional" or "alternate".
- The "alternate" specifies that this field can be
- return as an alternative to another one. An example
+ The "alternate" value specifies that this field can be
+ returned as an alternative to another one. An example
would be the network name or SSID.
All "mandatory" fields must be returned, while the
diff --git a/doc/backtrace.txt b/doc/backtrace.txt
index 951aa06a..fdeee090 100644
--- a/doc/backtrace.txt
+++ b/doc/backtrace.txt
@@ -8,7 +8,7 @@ backtrace will be dumped to syslog.
The ConnMan backtraces start with the following line:
++++++++ ConnMan backtrace ++++++++
and will try to display function names if those can be resolved from the stack
-addresses. All static functions name will not appeared for example.
+addresses. All static functions name will not appear for example.
For a more complete and useful stack frame output you can use the
test/backtrace script. It takes the actual binary that crashed and the
diff --git a/doc/counter-api.txt b/doc/counter-api.txt
index 9ec5f21b..32411d57 100644
--- a/doc/counter-api.txt
+++ b/doc/counter-api.txt
@@ -27,7 +27,7 @@ Methods void Release()
When "home" counter is active, then "roaming" counter
will contain an empty dictionary and vise-versa.
- The dictionary argument contains following entries:
+ The dictionary argument contains the following entries:
RX.Packets
diff --git a/doc/ipconfig-api.txt b/doc/ipconfig-api.txt
index 179e86fc..080fdac5 100644
--- a/doc/ipconfig-api.txt
+++ b/doc/ipconfig-api.txt
@@ -5,7 +5,7 @@ IP configuration handling
IP basics
=========
-The core IP handling is designed around network interfaces or more precise
+The core IP handling is designed around network interfaces or more precisely
what the Linux kernel handles as struct net_device. Via RTNL every interface
is tracked and an IP device created for it.
diff --git a/doc/overview-api.txt b/doc/overview-api.txt
index 926f9ebe..92ce2b90 100644
--- a/doc/overview-api.txt
+++ b/doc/overview-api.txt
@@ -37,7 +37,7 @@ the order of services in this list.
| Other WiMAX (strength 50) |
+---------------------------------------+
-If non of the services has been used before the sorting order will be done
+If none of the services has been used before the sorting order will be done
with these priorities:
1. Ethernet (lower index numbers first)
@@ -63,12 +63,12 @@ before others since it is more likely they are selected first. The signal
strength value is normalized to 0-100 (effectively a percentage) and allows
an easy sorting.
-If the signal strength is identical than the WiMAX network should be shown
+If the signal strength is identical then the WiMAX network should be shown
first since it is a licensed spectrum and more reliable. Also the number
of WiMAX networks will be smaller than the number of WiFi since that operates
in an unlicensed spectrum.
-WiFi networks with the same signal strength are then sorted by its security
+WiFi networks with the same signal strength are then sorted by their security
setting. WPA2 encrypted networks should be preferred over WPA/WEP and also
unencrypted ones. After that they will be sorted by the SSID in alphabetical
order.
@@ -122,13 +122,13 @@ remove the favorite selection.
| |
This means that all services with an order > 0 have favorite=yes and all
-other have favorite=no setting. The favorite setting is exposed via a
+others have favorite=no setting. The favorite setting is exposed via a
property over the service interface. As mentioned above, the order number
is only used internally.
-Within Connection Manager many service can be connected at the same time and
+Within Connection Manager many services can be connected at the same time and
also have an IP assignment. However only one can have the default route. The
-service with the the default route will always be sorted at the top of the
+service with the default route will always be sorted at the top of the
list.
+---------------------------------------+
@@ -230,8 +230,8 @@ In case of WiFi this will be the SSID value. The SSID is a binary array and
will be converted into printable form. Unprintable characters are replaced
with spaces.
-For WiMAX networks the provide name like Clear or X-OHM will be used. This
-name either comes directly from the networks itself or from a provisioning
+For WiMAX networks the provider name like Clear or X-OHM will be used. This
+name either comes directly from the network itself or from a provisioning
database of the WiMAX service.
For Bluetooth the device alias is used. The alias is different since it
@@ -382,7 +382,7 @@ just telling it to actually connect:
service.Connect() or service.Disconnect()
-It is possible to connect multiple service if the underlying technology
+It is possible to connect multiple services if the underlying technology
allows it. For example it would be possible to connect to a WiFi network
and a Bluetooth service at the same time. Trying to connect to a second WiFi
network with the same WiFi hardware would result in an automatic disconnect
@@ -393,7 +393,7 @@ can fail for one reason or another. Application should be able to handle
such errors and will also be notified of changes via signals.
In future versions Connection Manager will interact with an agent to confirm
-certain transaction with the user. This functionality is currently not
+certain transactions with the user. This functionality is currently not
implemented.
To monitor the current status of a service the state property can be used. It
@@ -403,6 +403,6 @@ gives detailed information about the current progress.
print properties["State"]
-All state changes are also send via the PropertyChanged signal on the
+All state changes are also sent via the PropertyChanged signal on the
service interface. This allows asynchronous monitoring without having to poll
Connection Manager for changes.
diff --git a/doc/plugin-api.txt b/doc/plugin-api.txt
index 696e2c16..b39c043a 100644
--- a/doc/plugin-api.txt
+++ b/doc/plugin-api.txt
@@ -7,7 +7,7 @@ Plugin basics
The Connection Manager supports plugins for various actions. The basic plugin
contains of plugin description via CONNMAN_PLUGIN_DEFINE and also init/exit
-callbacks definied through that description.
+callbacks defined through that description.
#include <connman/plugin.h>
diff --git a/doc/service-api.txt b/doc/service-api.txt
index d3097364..aaddbfbb 100644
--- a/doc/service-api.txt
+++ b/doc/service-api.txt
@@ -132,7 +132,7 @@ Properties string State [readonly]
The service error status details.
When error occur during connection or disconnection
- the detailed information are represented in this
+ the detailed information is represented in this
property to help the user interface to present the
user with alternate options.
@@ -198,7 +198,7 @@ Properties string State [readonly]
If the service type is WiFi, then this property
can be used to store a passphrase.
- No PropertyChanged signals will be send for this
+ No PropertyChanged signals will be sent for this
property. The PassphraseRequired property should
be monitored instead.