diff options
| author | Michele Calgaro <michele.calgaro@yahoo.it> | 2016-02-24 21:05:19 +0700 |
|---|---|---|
| committer | Michele Calgaro <michele.calgaro@yahoo.it> | 2016-02-24 21:05:19 +0700 |
| commit | 3ed5f6bda5dabbb74b0126982cb515de1a8e2558 (patch) | |
| tree | 51425d2c964dba9303bc58b55ada48727bc2a4e4 /kmobile/DESIGN | |
| parent | c2ad4a056c3fecc0643b92755bc851b2fa299c49 (diff) | |
| download | tdepim-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/DESIGN | 12 |
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 |