summaryrefslogtreecommitdiffstats
path: root/kmobile/DESIGN
diff options
context:
space:
mode:
authorMichele Calgaro <michele.calgaro@yahoo.it>2016-02-24 21:05:19 +0700
committerMichele Calgaro <michele.calgaro@yahoo.it>2016-02-24 21:05:19 +0700
commit3ed5f6bda5dabbb74b0126982cb515de1a8e2558 (patch)
tree51425d2c964dba9303bc58b55ada48727bc2a4e4 /kmobile/DESIGN
parentc2ad4a056c3fecc0643b92755bc851b2fa299c49 (diff)
downloadtdepim-3ed5f6bda5dabbb74b0126982cb515de1a8e2558.tar.gz
tdepim-3ed5f6bda5dabbb74b0126982cb515de1a8e2558.zip
Fixed FTBFS in Debian/Ubuntu due to missing liblockdev1-dev package. Device locking is now done through 'flock()'
Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>
Diffstat (limited to 'kmobile/DESIGN')
-rw-r--r--kmobile/DESIGN12
1 files changed, 6 insertions, 6 deletions
diff --git a/kmobile/DESIGN b/kmobile/DESIGN
index 90ea509ec..c8e28f068 100644
--- a/kmobile/DESIGN
+++ b/kmobile/DESIGN
@@ -7,7 +7,7 @@
"kmobile" is suite to easily access "Mobile Devices",
which means, that you have one single interface to access
-any type of mobile device (e.g. cellular phone, PDAs,
+any type of mobile device (e.g. cellular phone, PDAs,
MP3-Players, Digital Cameras and a lot more).
Each of this devices have different types of information,
@@ -17,11 +17,11 @@ Each of this devices have different types of information,
- calendar entries,
- a file storage section (e.g. pictures in digital cameras)
- and more
-
+
The whole interface is pretty extendable. Each device has
-a device driver, which reports the capatibilities of the
+a device driver, which reports the capatibilities of the
connected device to the higher level.
-So, if you once write a device driver, you can access it's
+So, if you once write a device driver, you can access it's
contents from any KDE application later.
Currently the whole interface is divided into 3 sections:
@@ -48,7 +48,7 @@ The mid-layer handles the main functionality, which is entirely
implemented in the kmobile application. All low-level drivers
are loaded by kmobile only, and then all low-level functions
to any device is made available to other applications
-with a DCOP interface. Normal KDE applications should prefer the
+with a DCOP interface. Normal KDE applications should prefer the
userland library (see below) instead of using direct DCOP calls.
Nevertheless, the DCOP interface might be very interesting to write
standalone command line tools.
@@ -86,7 +86,7 @@ HINTS FOR DRIVER DEVELOPERS:
all calls to your driver, so you always will have a clean state
- use lockDevice("/dev/ttyS1") and unlockDevice("/dev/ttyS1") to
- lock those devices system-wide (creates /var/lock/LCK..<devname> files),
+ lock those devices system-wide,
and to prevent other applications to access the same physical ports/devices
- use the helper functions createDirEntry() and createFileEntry() to