summaryrefslogtreecommitdiffstats
path: root/kmobile/DESIGN
diff options
context:
space:
mode:
authortpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2011-04-13 00:46:47 +0000
committertpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2011-04-13 00:46:47 +0000
commit67e29a054cfcb1b0d2fe6b0a316cf6b3eec087b7 (patch)
tree5f52a9eada2e9f3654fc327d7c14dfef570a6ecb /kmobile/DESIGN
parent2ee4bf4fd5eff93b2fbef0ff8e8063edffc5da5c (diff)
downloadtdepim-67e29a054cfcb1b0d2fe6b0a316cf6b3eec087b7.tar.gz
tdepim-67e29a054cfcb1b0d2fe6b0a316cf6b3eec087b7.zip
Initial conversion of kdepim to TQt
This will probably require some tweaking before it will build under Qt4, however Qt3 builds are OK. Any alterations this commit makes to kdepim behaviour under Qt3 are unintentional and should be fixed. git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdepim@1227832 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'kmobile/DESIGN')
-rw-r--r--kmobile/DESIGN36
1 files changed, 18 insertions, 18 deletions
diff --git a/kmobile/DESIGN b/kmobile/DESIGN
index 287a3d9a..96dea2b1 100644
--- a/kmobile/DESIGN
+++ b/kmobile/DESIGN
@@ -7,10 +7,10 @@
"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 tqdevice (e.g. cellular phone, PDAs,
MP3-Players, Digital Cameras and a lot more).
-Each of this devices have different types of information,
+Each of this tqdevices have different types of information,
(capatibilities) which can be:
- An addressbook
- A collection of notes
@@ -18,28 +18,28 @@ Each of this devices have different types of information,
- 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
-connected device to the higher level.
-So, if you once write a device driver, you can access it's
+The whole interface is pretty extendable. Each tqdevice has
+a tqdevice driver, which reports the capatibilities of the
+connected tqdevice to the higher level.
+So, if you once write a tqdevice driver, you can access it's
contents from any KDE application later.
Currently the whole interface is divided into 3 sections:
-a) The low-level device driver
+a) The low-level tqdevice driver
b) A mid-layer, which is realized in the "kmobile" application
c) A userland library, to which KDE applications should link.
Here is some background info:
-a) The low-level device driver (libkmobile_xxxx.so)
+a) The low-level tqdevice driver (libkmobile_xxxx.so)
The low-level driver has to be derived from the KMobileDevice class
(#include <kmobiledevice.h>). The drivers should be located below the
-directory /device, and you can find a sample implementation in
-/device/skeleton-directory. See below for some hints on how to
-write such a device driver.
+directory /tqdevice, and you can find a sample implementation in
+/tqdevice/skeleton-directory. See below for some hints on how to
+write such a tqdevice driver.
b) The mid-layer (kmobile)
@@ -47,7 +47,7 @@ b) The mid-layer (kmobile)
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
+to any tqdevice is made available to other applications
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
@@ -56,14 +56,14 @@ standalone command line tools.
c) The userland library (libkmobileclient.so)
-Any KDE application which wants to access mobile devices
+Any KDE application which wants to access mobile tqdevices
should #include <kmobileclient.h> and link to the libkmobileclient.la
library. libkmobileclient translates all calls to DCOP calls and
-makes accessing mobile devices completely transparent to the
+makes accessing mobile tqdevices completely transparent to the
application.
One sample program which uses the client library is the kmobile
-kioslave. In Konqueror you might access any mobile device directly
+kioslave. In Konqueror you might access any mobile tqdevice directly
by giving "mobile:/" as the URL.
@@ -72,7 +72,7 @@ by giving "mobile:/" as the URL.
HINTS FOR DRIVER DEVELOPERS:
----------------------------
-- KMobile device drivers are very similiar to kioslaves. Refer
+- KMobile tqdevice drivers are very similiar to kioslaves. Refer
at the kioslave documentation if needed.
- derive your driver only from the KMobileDevice class (#include <kmobiledevice.h>)
@@ -86,8 +86,8 @@ 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),
- and to prevent other applications to access the same physical ports/devices
+ lock those tqdevices system-wide (creates /var/lock/LCK..<devname> files),
+ and to prevent other applications to access the same physical ports/tqdevices
- use the helper functions createDirEntry() and createFileEntry() to
create the right UDSEntries for listEntries(), stat(), ...