Revert "Rename a number of old tq methods that are no longer tq specific"

This reverts commit 3ca10fd9a2dc631429d3b5d5c5e42a7d211d5a12.

1 files changed, 18 insertions, 18 deletions

diff --git a/kmobile/DESIGN b/kmobile/DESIGN
index 287a3d9a2..96dea2b1b 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(), ...