From 716a5de8870d7c02bb4d0aed72f30291b17b763a Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Mon, 19 Dec 2011 11:59:01 -0600 Subject: Remove additional unneeded tq method conversions --- kmobile/DESIGN | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) (limited to 'kmobile/DESIGN') diff --git a/kmobile/DESIGN b/kmobile/DESIGN index 96dea2b1b..287a3d9a2 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 tqdevice (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 tqdevices have different types of information, +Each of this devices have different types of information, (capatibilities) which can be: - An addressbook - A collection of notes @@ -18,28 +18,28 @@ Each of this tqdevices have different types of information, - a file storage section (e.g. pictures in digital cameras) - and more -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 +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 contents from any KDE application later. Currently the whole interface is divided into 3 sections: -a) The low-level tqdevice driver +a) The low-level device 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 tqdevice driver (libkmobile_xxxx.so) +a) The low-level device driver (libkmobile_xxxx.so) The low-level driver has to be derived from the KMobileDevice class (#include ). The drivers should be located below the -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. +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. 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 tqdevice is made available to other applications +to any device 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 tqdevices +Any KDE application which wants to access mobile devices should #include and link to the libkmobileclient.la library. libkmobileclient translates all calls to DCOP calls and -makes accessing mobile tqdevices completely transparent to the +makes accessing mobile devices completely transparent to the application. One sample program which uses the client library is the kmobile -kioslave. In Konqueror you might access any mobile tqdevice directly +kioslave. In Konqueror you might access any mobile device directly by giving "mobile:/" as the URL. @@ -72,7 +72,7 @@ by giving "mobile:/" as the URL. HINTS FOR DRIVER DEVELOPERS: ---------------------------- -- KMobile tqdevice drivers are very similiar to kioslaves. Refer +- KMobile device drivers are very similiar to kioslaves. Refer at the kioslave documentation if needed. - derive your driver only from the KMobileDevice class (#include ) @@ -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 tqdevices system-wide (creates /var/lock/LCK.. files), - and to prevent other applications to access the same physical ports/tqdevices + lock those devices system-wide (creates /var/lock/LCK.. files), + and to prevent other applications to access the same physical ports/devices - use the helper functions createDirEntry() and createFileEntry() to create the right UDSEntries for listEntries(), stat(), ... -- cgit v1.2.1