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

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

1 files changed, 47 insertions, 47 deletions

diff --git a/doc/object.doc b/doc/object.doc
index 79e75c50d..f38389d02 100644
--- a/doc/object.doc
+++ b/doc/object.doc
@@ -69,7 +69,7 @@ Qt adds these features to C++:
 \endlist
 
 Many of these TQt features are implemented with standard C++
-techniques, based on inheritance from \l QObject. Others, like the
+techniques, based on inheritance from \l TQObject. Others, like the
 object communication mechanism and the dynamic property system,
 require the \link metaobjects.html Meta Object System \endlink provided
 by Qt's own \link moc.html Meta Object Compiler (moc) \endlink. 
@@ -91,11 +91,11 @@ slots? \endlink.
 
 \title Timers
 
-\l QObject, the base class of all TQt objects, provides the basic timer
-support in Qt. With \l QObject::startTimer(), you start a timer with
+\l TQObject, the base class of all TQt objects, provides the basic timer
+support in Qt. With \l TQObject::startTimer(), you start a timer with
 an \e interval in milliseconds as argument. The function returns a
 unique integer timer id. The timer will now "fire" every \e interval
-milliseconds, until you explicitly call \l QObject::killTimer() with
+milliseconds, until you explicitly call \l TQObject::killTimer() with
 the timer id.
 
 For this mechanism to work, the application must run in an event
@@ -114,7 +114,7 @@ can handle 1 millisecond intervals.
 
 The main API for the timer functionality is \l QTimer. That class
 provides regular timers that emit a signal when the timer fires, and
-inherits \l QObject so that it fits well into the ownership structure
+inherits \l TQObject so that it fits well into the ownership structure
 of most GUI programs. The normal way of using it is like this:
 \code
     QTimer * counter = new QTimer( this );
@@ -147,16 +147,16 @@ single-threaded application without blocking the user interface.
   \code
     // The Mandelbrot class uses a QTimer to calculate the mandelbrot
     // set one scanline at a time without blocking the CPU. It
-    // inherits QObject to use signals and slots. Calling start()
+    // inherits TQObject to use signals and slots. Calling start()
     // starts the calculation. The done() signal is emitted when it
     // has finished. Note that this example is not complete, just an
     // outline.
 
-    class Mandelbrot : public QObject
+    class Mandelbrot : public TQObject
     {
 	TQ_OBJECT // required for signals/slots
     public:
-	Mandelbrot( QObject *parent=0, const char *name );
+	Mandelbrot( TQObject *parent=0, const char *name );
 	...
     public slots:
 	void start();
@@ -173,8 +173,8 @@ single-threaded application without blocking the user interface.
     // Constructs and initializes a Mandelbrot object.
     //
 
-    Mandelbrot::Mandelbrot( QObject *parent=0, const char *name )
-    : QObject( parent, name )
+    Mandelbrot::Mandelbrot( TQObject *parent=0, const char *name )
+    : TQObject( parent, name )
     {
 	connect( &timer, SIGNAL(timeout()), SLOT(calculate()) );
 	...
@@ -225,7 +225,7 @@ through \link signalsandslots.html signals and slots\endlink.
 
 The \c TQ_PROPERTY macro in a class declaration declares a
 property. Properties can only be declared in classes that inherit \l
-QObject. A second macro, \c TQ_OVERRIDE, can be used to override some
+TQObject. A second macro, \c TQ_OVERRIDE, can be used to override some
 aspects of an inherited property in a subclass. (See \link #override
 TQ_OVERRIDE\endlink.)
 
@@ -237,16 +237,16 @@ ordinary data members:
 \i A read function. This always exists.
 
 \i A write function. This is optional: read-only properties like \l
-QWidget::isDesktop() do not have one.
+TQWidget::isDesktop() do not have one.
 
 \i An attribute "stored" that indicates persistence. Most properties
 are stored, but a few virtual properties are not. For example, \l
-QWidget::minimumWidth() isn't stored, since it's just a view of
-\l QWidget::minimumSize(), and has no data of its own.
+TQWidget::minimumWidth() isn't stored, since it's just a view of
+\l TQWidget::minimumSize(), and has no data of its own.
 
 \i A reset function to set a property back to its context specific
-default value. This is very rare, but for example, \l QWidget::font()
-needs this, since no call to \l QWidget::setFont() can mean 'reset to
+default value. This is very rare, but for example, \l TQWidget::font()
+needs this, since no call to \l TQWidget::setFont() can mean 'reset to
 the context specific font'.
 
 \i An attribute "designable" that indicates whether it makes sense to
@@ -262,11 +262,11 @@ The read, write, and reset functions must be public member functions
 from the class in which the property is defined.
 
 Properties can be read and written through generic functions in
-QObject without knowing anything about the class in use. These two
+TQObject without knowing anything about the class in use. These two
 function calls are equivalent:
 
 \code
-    // QButton *b and QObject *o point to the same button
+    // QButton *b and TQObject *o point to the same button
     b->setDown( TRUE );
     o->setProperty( "down", TRUE );
 \endcode
@@ -274,12 +274,12 @@ function calls are equivalent:
 Equivalent, that is, except that the first is faster, and provides
 much better diagnostics at compile time. When practical, the first is
 better. However, since you can get a list of all available properties
-for any QObject through its \l QMetaObject, \l QObject::setProperty()
+for any TQObject through its \l QMetaObject, \l TQObject::setProperty()
 can give you control over classes that weren't available at compile
 time.
 
-As well as QObject::setProperty(), there is a corresponding \l
-QObject::property() function. \l QMetaObject::propertyNames() returns
+As well as TQObject::setProperty(), there is a corresponding \l
+TQObject::property() function. \l QMetaObject::propertyNames() returns
 the names of all available properties. \l QMetaObject::property()
 returns the property data for a named property: a \l QMetaProperty
 object.
@@ -288,11 +288,11 @@ Here's a simple example that shows the most important property
 functions in use:
 
 \code
-    class MyClass : public QObject
+    class MyClass : public TQObject
     {
         TQ_OBJECT
     public:
-        MyClass( QObject * parent=0, const char * name=0 );
+        MyClass( TQObject * parent=0, const char * name=0 );
         ~MyClass();
 
         enum Priority { High, Low, VeryHigh, VeryLow };
@@ -324,7 +324,7 @@ registered with the property system as well.
 
 There are two exceptions to the above: The type of a property can also
 be either \link QValueList QValueList\<QVariant\>\endlink or \link
-QMap QMap\<QString,QVariant\>\endlink. In
+QMap QMap\<TQString,QVariant\>\endlink. In
 these cases the type must be specified as \c QValueList or as \c QMap
 (i.e. without their template parameters).
 
@@ -339,13 +339,13 @@ Enumeration types are registered with the \c TQ_ENUMS macro. Here's the
 final class declaration including the property related declarations:
 
 \code
-    class MyClass : public QObject
+    class MyClass : public TQObject
     {
         TQ_OBJECT
         TQ_PROPERTY( Priority priority READ priority WRITE setPriority )
         TQ_ENUMS( Priority )
     public:
-        MyClass( QObject * parent=0, const char * name=0 );
+        MyClass( TQObject * parent=0, const char * name=0 );
         ~MyClass();
 
         enum Priority { High, Low, VeryHigh, VeryLow };
@@ -397,16 +397,16 @@ through the meta object, see \l QMetaObject::classInfo() for details.
 \target override
 \section1 TQ_OVERRIDE
 
-When you inherit a QObject subclass you may wish to override some
+When you inherit a TQObject subclass you may wish to override some
 aspects of some of the class's properties.
 
-For example, in QWidget we have the autoMask property defined like
+For example, in TQWidget we have the autoMask property defined like
 this:
 \code
     TQ_PROPERTY( bool autoMask READ autoMask WRITE setAutoMask DESIGNABLE false SCRIPTABLE false )
 \endcode
 
-But we need to make the auto mask property designable in some QWidget
+But we need to make the auto mask property designable in some TQWidget
 subclasses. Similarly some classes will need this property to be
 scriptable (e.g. for QSA). This is achieved by overriding these
 features of the property in a subclass. In QCheckBox, for example, we
@@ -439,10 +439,10 @@ buttons.
 \title Events and Event Filters
 
 In Qt, an event is an object that inherits \l QEvent. Events are
-delivered to objects that inherit \l QObject through calling \l
-QObject::event(). Event delivery means that an event has occurred, the
-QEvent indicates precisely what, and the QObject needs to respond. Most
-events are specific to \l QWidget and its subclasses, but there are
+delivered to objects that inherit \l TQObject through calling \l
+TQObject::event(). Event delivery means that an event has occurred, the
+QEvent indicates precisely what, and the TQObject needs to respond. Most
+events are specific to \l TQWidget and its subclasses, but there are
 important events that aren't related to graphics, for example, socket
 activation, which is the event used by \l QSocketNotifier for its
 work.
@@ -471,7 +471,7 @@ will explain enough for 99% of applications.
 
 The normal way for an event to be delivered is by calling a virtual
 function. For example, \l QPaintEvent is delivered by calling \l
-QWidget::paintEvent(). This virtual function is responsible for
+TQWidget::paintEvent(). This virtual function is responsible for
 reacting appropriately, normally by repainting the widget. If you
 do not perform all the necessary work in your implementation of the
 virtual function, you may need to call the base class's
@@ -491,10 +491,10 @@ the base class.
 
 Occasionally there isn't such an event-specific function, or the
 event-specific function isn't sufficient. The most common example is
-tab key presses. Normally, those are interpreted by QWidget to move
+tab key presses. Normally, those are interpreted by TQWidget to move
 the keyboard focus, but a few widgets need the tab key for themselves.
 
-These objects can reimplement \l QObject::event(), the general event
+These objects can reimplement \l TQObject::event(), the general event
 handler, and either do their event handling before or after the usual
 handling, or replace it completely. A very unusual widget that both
 interprets tab and has an application-specific custom event might
@@ -514,17 +514,17 @@ contain:
 	  // custom event handling here
 	  return TRUE;
       }
-      return QWidget::event( evt );
+      return TQWidget::event( evt );
   }
 \endcode
 
 More commonly, an object needs to look at another's events. Qt
-supports this using \l QObject::installEventFilter() (and the
+supports this using \l TQObject::installEventFilter() (and the
 corresponding remove). For example, dialogs commonly want to filter
 key presses for some widgets, e.g. to modify Return-key handling.
 
 An event filter gets to process events before the target object does.
-The filter's \l QObject::eventFilter() implementation is called, and
+The filter's \l TQObject::eventFilter() implementation is called, and
 can accept or reject the filter, and allow or deny further processing
 of the event. If all the event filters allow further processing of an
 event, the event is sent to the target object itself. If one of them
@@ -556,7 +556,7 @@ postEvent() posts the event on a queue for later dispatch. The next
 time Qt's main event loop runs, it dispatches all posted events, with
 some optimization. For example, if there are several resize events,
 they are are compacted into one. The same applies to paint events: \l
-QWidget::update() calls postEvent(), which minimizes flickering and
+TQWidget::update() calls postEvent(), which minimizes flickering and
 increases speed by avoiding multiple repaints.
 
 postEvent() is also often used during object initialization, since the
@@ -577,18 +577,18 @@ details.
 
 \title Object Trees and Object Ownership
 
-\link QObject QObjects\endlink organize themselves in object trees.
-When you create a QObject with another object as parent, it's added to
-the parent's \link QObject::children() children() \endlink list, and
+\link TQObject QObjects\endlink organize themselves in object trees.
+When you create a TQObject with another object as parent, it's added to
+the parent's \link TQObject::children() children() \endlink list, and
 is deleted when the parent is. It turns out that this approach fits
 the needs of GUI objects very well. For example, a \l QAccel (keyboard
 accelerator) is a child of the relevant window, so when the user closes
 that window, the accelerator is deleted too.
 
-The static function \l QObject::objectTrees() provides access to all
+The static function \l TQObject::objectTrees() provides access to all
 the root objects that currently exist.
 
-\l QWidget, the base class of everything that appears on the screen,
+\l TQWidget, the base class of everything that appears on the screen,
 extends the parent-child relationship. A child normally also becomes a
 child widget, i.e. it is displayed in its parent's coordinate system
 and is graphically clipped by its parent's boundaries. For example,
@@ -603,8 +603,8 @@ toolbar it may lead to the application deleting one of its \l QToolBar
 objects, in which case the tool bar's \l QMainWindow parent would
 detect the change and reconfigure its screen space accordingly.
 
-The debugging functions \l QObject::dumpObjectTree() and \l
-QObject::dumpObjectInfo() are often useful when an application looks or
+The debugging functions \l TQObject::dumpObjectTree() and \l
+TQObject::dumpObjectInfo() are often useful when an application looks or
 acts strangely.
 
 */