Revert automated changes

Sorry guys, they are just not ready for prime time
Work will continue as always


git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdelibs@1212479 283d02a7-25f6-0310-bc7c-ecb5cbfe19da

1 files changed, 6 insertions, 6 deletions

diff --git a/dcop/Mainpage.dox b/dcop/Mainpage.dox
index 9e0bec658..d573b01b5 100644
--- a/dcop/Mainpage.dox
+++ b/dcop/Mainpage.dox
@@ -148,7 +148,7 @@ else {
 
 Currently the only real way to receive data from DCOP is to multiply
 inherit from the normal class that you are inheriting (usually some
-sort of QWidget subclass or TQObject) as well as the DCOPObject class.
+sort of QWidget subclass or QObject) as well as the DCOPObject class.
 DCOPObject provides one very important method: DCOPObject::process().
 This is a pure virtual method that you must implement in order to
 process DCOP messages that you receive.  It takes a function
@@ -289,7 +289,7 @@ but virtual, not pure virtual.
 Example:
 
 \code
-class MyClass: public TQObject, virtual public MyInterface
+class MyClass: public QObject, virtual public MyInterface
 {
   Q_OBJECT
 
@@ -301,7 +301,7 @@ class MyClass: public TQObject, virtual public MyInterface
     QRect mySynchronousMethod();
 };
 \endcode
-\note (Qt issue) Remember that if you are inheriting from TQObject, you must
+\note (Qt issue) Remember that if you are inheriting from QObject, you must
 place it first in the list of inherited classes.
 
 In the implementation of your class' ctor, you must explicitly initialize
@@ -313,7 +313,7 @@ Example:
 
 \code
 MyClass::MyClass()
-  : TQObject(),
+  : QObject(),
     DCOPObject("MyInterface")
 {
   // whatever...
@@ -338,7 +338,7 @@ abstract class of its own, like we did in the example above. We could
 just as well have defined a k_dcop section directly within MyClass:
 
 \code
-class MyClass: public TQObject, virtual public DCOPObject
+class MyClass: public QObject, virtual public DCOPObject
 {
   Q_OBJECT
   K_DCOP
@@ -373,7 +373,7 @@ b) the authentication must be ensured
 For the first step, you simply pass the server address (as
 found in .DCOPserver) to the second process. For the authentication,
 you can use the ICEAUTHORITY environment variable to tell the
-second process where to tqfind the authentication information.
+second process where to find the authentication information.
 (Note that this implies that the second process is able to
 read the authentication file, so it will probably only work
 if the second process runs as root. If it should run as another