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, 15 insertions, 15 deletions

diff --git a/doc/hackers.guide.txt b/doc/hackers.guide.txt
index 8d8c0c0a..2b092285 100644
--- a/doc/hackers.guide.txt
+++ b/doc/hackers.guide.txt
@@ -400,29 +400,29 @@ This is the list of the various string types used in KVIrc.
 	
 KviStr
 	The basic KVIrc string class. It has been first implemented as a hack
-	around various bugs of the original QString class (the NOT unicode one
+	around various bugs of the original TQString class (the NOT unicode one
 	that now has been renamed to QCString). It has the property of being
 	always non null and it has no reference counting.
-	Actually many occurences of this string are replaced by QString
+	Actually many occurences of this string are replaced by TQString
 	(especially in GUI modules) to handle correctly the UNICODE character set.
 
-QString
+TQString
 	The Qt UNICODE string. See the Qt documentation for details.
 	This is the string that should be mostly used in KVIrc in the near future.
 	Take care: in general it is NOT null terminated.
 	There is a KviQString wrapper namespace (#include "kvi_qstring.h") that
 	adds some missing functionality. For example,
 		KviQString::sprintf(qstring_buffer,qstring_format,...)
-	allows formatting a QString with a format string that is a QString itself
+	allows formatting a TQString with a format string that is a TQString itself
 	(and thus it is UNICODE).
-	QString uses reference counting. An assigment of a QString to another
-	QString does NOT make an immediate copy, it just increases the reference
+	TQString uses reference counting. An assigment of a TQString to another
+	TQString does NOT make an immediate copy, it just increases the reference
 	count instead. The copy is made at the first modification of one of the
 	two strings (the operation is called "detaching"). While generally this
-	is not an issue, you must take care when passing QString objects between
+	is not an issue, you must take care when passing TQString objects between
 	concurrent threads.
 
-(const) QChar * 
+(const) TQChar * 
     The array of Qt chars. This is usually obtained by callling
     KviQString::nullTerminatedArray() which itself is a hack...
     This array is used in some functions that were written for
@@ -435,7 +435,7 @@ The Goal:
 	- Use KviStr only where it is strictly needed (for protocol or performance
 		related issues). One of such places is the IRC server parser (but there
 		are more).
-	- Use QString everywhere in the user interface and in any other
+	- Use TQString everywhere in the user interface and in any other
 		place where KviStr is not strictly needed. Save and restore
 		strings in the UTF8 format.
 	- Get rid of ALL occurences of KviWStr and kvi_wchar_t * : DONE on 2004.11.02
@@ -449,7 +449,7 @@ language. To make a string translaetable use one of the __tr* macros.
 The most common one across the sources is __tr("string") that returns
 a const char * translation of "string".
 Actually __tr() is being phased out in favor of __tr2qs() that returns
-a QString instead of a const char * pointer.
+a TQString instead of a const char * pointer.
 The arguments of these macros are extracted from the sources by the
 gettext program and are used to build the translation hashes loaded at runtime.
 Remember that the arguments must be string constants and not variables.
@@ -459,7 +459,7 @@ defined in kvi_locale.h
 
 CSTRING is an US-ASCII null terminated C string.
 
-__tr2qs(CSTRING) : translates CSTRING to a QString &
+__tr2qs(CSTRING) : translates CSTRING to a TQString &
 __tr(CSTRING) : translates CSTRING to another CSTRING
 	This should disappear in favor of __tr2qs
 
@@ -694,11 +694,11 @@ comes from the server) you MUST use KviWindow::outputNoFmt() instead
 of KviWindow::output().
 
 BAD:
-	QString szText = pConnection->decodeText(msg.safeTrailing());
+	TQString szText = pConnection->decodeText(msg.safeTrailing());
 	pWindow->output(KVI_OUT_SOMETHING,szText); <--potential crash/security hole
 
 GOOD:
-	QString szText = pConnection->decodeText(msg.safeTrailing());
+	TQString szText = pConnection->decodeText(msg.safeTrailing());
 	pWindow->outputNoFmt(KVI_OUT_SOMETHING,szText); <--faster and no crashes
 
 -------------------------------------------------------------------------------
@@ -861,11 +861,11 @@ Porting to Qt 4.x (while mantaining Qt 3.x compatibility) (Work In Progress)
 
 For the moment, in random order:
 
-- Avoid using QString::null, use KviQString::empty instead.
+- Avoid using TQString::null, use KviQString::empty instead.
   This is because Qt 4.x does NOT have a null static variable. Qt 4.x in fact
   does not have the distinction between null and empty strings (Note that for
   KviStr this choice was made since the beginning).
-  Do NOT replace all the uses of QString::null with QString() (as the qt 4.x
+  Do NOT replace all the uses of TQString::null with TQString() (as the qt 4.x
   porting documentation suggests) since for Qt 3.x this construct is SLOW.
 
 - We're building a compatibility layer in kvilib.