Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version

Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>

doc/html/_sources/annotations.txt

@@ -55,7 +55,7 @@ Annotations can have one of the following types:
 
 The following example shows argument and function annotations::
 
-    void exec(QWidget * /Transfer/) /ReleaseGIL, PyName=call_exec/;
+    void exec(TQWidget * /Transfer/) /ReleaseGIL, PyName=call_exec/;
 
 Note that the current version of SIP does not complain about unknown
 annotations, or annotations used out of their correct context.

doc/html/_sources/directives.txt

@@ -370,8 +370,8 @@ PyObject \*sipTransferObj
 The handwritten code must explicitly return a ``PyObject *``.  If there was an
 error then a Python exception must be raised and ``NULL`` returned.
 
-The following example converts a ``QPtrList<QWidget *>`` instance to a Python
-list of ``QWidget`` instances::
+The following example converts a ``QPtrList<TQWidget *>`` instance to a Python
+list of ``TQWidget`` instances::
 
     %ConvertFromTypeCode
         PyObject *l;
@@ -381,13 +381,13 @@ list of ``QWidget`` instances::
             return NULL;
 
         // Go through each element in the C++ instance and convert it to a
-        // wrapped QWidget.
+        // wrapped TQWidget.
         for (int i = 0; i < sipCpp->size(); ++i)
         {
-            QWidget *w = sipCpp->at(i);
+            TQWidget *w = sipCpp->at(i);
             PyObject *wobj;
 
-            // Get the Python wrapper for the QWidget instance, creating a new
+            // Get the Python wrapper for the TQWidget instance, creating a new
             // one if necessary, and handle any ownership transfer.
             if ((wobj = sipConvertFromType(w, sipType_QWidget, sipTransferObj)) == NULL)
             {
@@ -514,8 +514,8 @@ the correct type prior to conversion.
 
 When used as part of a class specification it can automatically convert
 additional types of Python object.  For example, PyQt uses it in the
-specification of the ``QString`` class to allow Python string objects and
-unicode objects to be used wherever ``QString`` instances are expected.
+specification of the ``TQString`` class to allow Python string objects and
+unicode objects to be used wherever ``TQString`` instances are expected.
 
 The following variables are made available to the handwritten code:
 
@@ -1395,9 +1395,9 @@ For example::
     %End
     }
 
-Using this we can use, for example, ``QPtrList<QObject *>`` throughout the
+Using this we can use, for example, ``QPtrList<TQObject *>`` throughout the
 module's specification files (and in any module that imports this one).  The
-generated code will automatically map this to and from a Python list of QObject
+generated code will automatically map this to and from a Python list of TQObject
 instances when appropriate.
 
 

doc/html/_sources/using.txt

@@ -217,7 +217,7 @@ The ``hello.h`` header file looks something like this::
         TQ_OBJECT
 
     public:
-        Hello(QWidget *parent = 0);
+        Hello(TQWidget *parent = 0);
 
     private:
         // Prevent instances from being copied.
@@ -226,7 +226,7 @@ The ``hello.h`` header file looks something like this::
     };
 
     #if !defined(Q_OS_WIN)
-    void setDefault(const QString &def);
+    void setDefault(const TQString &def);
     #endif
 
 The corresponding SIP specification file would then look something like this::
@@ -246,14 +246,14 @@ The corresponding SIP specification file would then look something like this::
     %End
 
     public:
-        Hello(QWidget *parent /TransferThis/ = 0);
+        Hello(TQWidget *parent /TransferThis/ = 0);
 
     private:
         Hello(const Hello &);
     };
 
     %If (!WS_WIN)
-    void setDefault(const QString &def);
+    void setDefault(const TQString &def);
     %End
 
     %End
@@ -283,7 +283,7 @@ previous examples.
       argument.  It specifies that if the argument is not 0 (i.e. the ``Hello``
       instance being constructed has a parent) then ownership of the instance
       is transferred from Python to C++.  It is needed because Qt maintains
-      objects (i.e. instances derived from the ``QObject`` class) in a
+      objects (i.e. instances derived from the ``TQObject`` class) in a
       hierachy.  When an object is destroyed all of its children are also
       automatically destroyed.  It is important, therefore, that the Python
       garbage collector doesn't also try and destroy them.  This is covered in
@@ -515,9 +515,9 @@ As an example, PyQt4 uses :directive:`%DefaultMetatype` to specify a new
 meta-type that handles the interaction with Qt's own meta-type system.  It also
 uses :directive:`%DefaultSupertype` to specify that the smaller
 :class:`sip.simplewrapper` super-type is normally used.  Finally it uses
-:canno:`Supertype` as an annotation of the ``QObject`` class to override the
+:canno:`Supertype` as an annotation of the ``TQObject`` class to override the
 default and use :class:`sip.wrapper` as the super-type so that the parent/child
-relationships of ``QObject`` instances are properly maintained.
+relationships of ``TQObject`` instances are properly maintained.
 
 
 .. _ref-lazy-type-attributes:

sphinx/annotations.rst

@@ -55,7 +55,7 @@ Annotations can have one of the following types:
 
 The following example shows argument and function annotations::
 
-    void exec(QWidget * /Transfer/) /ReleaseGIL, PyName=call_exec/;
+    void exec(TQWidget * /Transfer/) /ReleaseGIL, PyName=call_exec/;
 
 Note that the current version of SIP does not complain about unknown
 annotations, or annotations used out of their correct context.

sphinx/directives.rst

@@ -370,8 +370,8 @@ PyObject \*sipTransferObj
 The handwritten code must explicitly return a ``PyObject *``.  If there was an
 error then a Python exception must be raised and ``NULL`` returned.
 
-The following example converts a ``QPtrList<QWidget *>`` instance to a Python
-list of ``QWidget`` instances::
+The following example converts a ``QPtrList<TQWidget *>`` instance to a Python
+list of ``TQWidget`` instances::
 
     %ConvertFromTypeCode
         PyObject *l;
@@ -381,13 +381,13 @@ list of ``QWidget`` instances::
             return NULL;
 
         // Go through each element in the C++ instance and convert it to a
-        // wrapped QWidget.
+        // wrapped TQWidget.
         for (int i = 0; i < sipCpp->size(); ++i)
         {
-            QWidget *w = sipCpp->at(i);
+            TQWidget *w = sipCpp->at(i);
             PyObject *wobj;
 
-            // Get the Python wrapper for the QWidget instance, creating a new
+            // Get the Python wrapper for the TQWidget instance, creating a new
             // one if necessary, and handle any ownership transfer.
             if ((wobj = sipConvertFromType(w, sipType_QWidget, sipTransferObj)) == NULL)
             {
@@ -514,8 +514,8 @@ the correct type prior to conversion.
 
 When used as part of a class specification it can automatically convert
 additional types of Python object.  For example, PyQt uses it in the
-specification of the ``QString`` class to allow Python string objects and
-unicode objects to be used wherever ``QString`` instances are expected.
+specification of the ``TQString`` class to allow Python string objects and
+unicode objects to be used wherever ``TQString`` instances are expected.
 
 The following variables are made available to the handwritten code:
 
@@ -1395,9 +1395,9 @@ For example::
     %End
     }
 
-Using this we can use, for example, ``QPtrList<QObject *>`` throughout the
+Using this we can use, for example, ``QPtrList<TQObject *>`` throughout the
 module's specification files (and in any module that imports this one).  The
-generated code will automatically map this to and from a Python list of QObject
+generated code will automatically map this to and from a Python list of TQObject
 instances when appropriate.
 
 

sphinx/using.rst

@@ -217,7 +217,7 @@ The ``hello.h`` header file looks something like this::
         TQ_OBJECT
 
     public:
-        Hello(QWidget *parent = 0);
+        Hello(TQWidget *parent = 0);
 
     private:
         // Prevent instances from being copied.
@@ -226,7 +226,7 @@ The ``hello.h`` header file looks something like this::
     };
 
     #if !defined(Q_OS_WIN)
-    void setDefault(const QString &def);
+    void setDefault(const TQString &def);
     #endif
 
 The corresponding SIP specification file would then look something like this::
@@ -246,14 +246,14 @@ The corresponding SIP specification file would then look something like this::
     %End
 
     public:
-        Hello(QWidget *parent /TransferThis/ = 0);
+        Hello(TQWidget *parent /TransferThis/ = 0);
 
     private:
         Hello(const Hello &);
     };
 
     %If (!WS_WIN)
-    void setDefault(const QString &def);
+    void setDefault(const TQString &def);
     %End
 
     %End
@@ -283,7 +283,7 @@ previous examples.
       argument.  It specifies that if the argument is not 0 (i.e. the ``Hello``
       instance being constructed has a parent) then ownership of the instance
       is transferred from Python to C++.  It is needed because TQt maintains
-      objects (i.e. instances derived from the ``QObject`` class) in a
+      objects (i.e. instances derived from the ``TQObject`` class) in a
       hierachy.  When an object is destroyed all of its children are also
       automatically destroyed.  It is important, therefore, that the Python
       garbage collector doesn't also try and destroy them.  This is covered in
@@ -515,9 +515,9 @@ As an example, PyQt4 uses :directive:`%DefaultMetatype` to specify a new
 meta-type that handles the interaction with Qt's own meta-type system.  It also
 uses :directive:`%DefaultSupertype` to specify that the smaller
 :class:`sip.simplewrapper` super-type is normally used.  Finally it uses
-:canno:`Supertype` as an annotation of the ``QObject`` class to override the
+:canno:`Supertype` as an annotation of the ``TQObject`` class to override the
 default and use :class:`sip.wrapper` as the super-type so that the parent/child
-relationships of ``QObject`` instances are properly maintained.
+relationships of ``TQObject`` instances are properly maintained.
 
 
 .. _ref-lazy-type-attributes: