summaryrefslogtreecommitdiffstats
path: root/python/pykde/doc/dcopext.html
diff options
context:
space:
mode:
Diffstat (limited to 'python/pykde/doc/dcopext.html')
-rw-r--r--python/pykde/doc/dcopext.html76
1 files changed, 38 insertions, 38 deletions
diff --git a/python/pykde/doc/dcopext.html b/python/pykde/doc/dcopext.html
index b9eef077..2045a2eb 100644
--- a/python/pykde/doc/dcopext.html
+++ b/python/pykde/doc/dcopext.html
@@ -159,30 +159,30 @@ The DCOP extensions will support any of the following C++ data types:
<TR><TD>unsigned int</TD><TD>unsigned long</TD><TD>uchar</TD></TR>
<TR><TD>ushsort</TD><TD>uint</TD><TD>ulong</TD></TR>
<TR><TD>Q_INT32</TD><TD>pid_t</TD><TD>float</TD></TR>
-<TR><TD>double</TD><TD>QString</TD><TD>QStringList</TD></TR>
-<TR><TD>QCString</TD><TD>KURL</TD><TD>KURL::List</TD></TR>
-<TR><TD>QSize</TD><TD>QRect</TD><TD>QRegion</TD></TR>
-<TR><TD>QFont</TD><TD>QCursor</TD><TD>QPixmap</TD></TR>
-<TR><TD>QColor</TD><TD>QColorGroup</TD><TD>QPalette</TD></TR>
-<TR><TD>QBrush</TD><TD>QWidget::FocusPolicy</TD><TD>DCOPRef</TD></TR>
-<TR><TD>QVariant</TD><TD>QDate</TD><TD>QTime</TD></TR>
-<TR><TD>QDateTime</TD><TD>QImage</TD><TD>QKeySequence</TD></TR>
-<TR><TD>QPen</TD><TD>QPicture</TD><TD>QPointArray</TD></TR>
-<TR><TD>QValueList&lt;DCOPRef&gt;</TD><TD>QValueList&lt;QCString&gt;</TD><TD>QMap&lt;QCString,DCOPRef&gt;</TD></TR>
-<TR><TD>QMap&lt;QCString,DCOPRef&gt;</TD><TD></TD><TD></TD></TR>
+<TR><TD>double</TD><TD>TQString</TD><TD>TQStringList</TD></TR>
+<TR><TD>TQCString</TD><TD>KURL</TD><TD>KURL::List</TD></TR>
+<TR><TD>TQSize</TD><TD>TQRect</TD><TD>TQRegion</TD></TR>
+<TR><TD>TQFont</TD><TD>TQCursor</TD><TD>TQPixmap</TD></TR>
+<TR><TD>TQColor</TD><TD>TQColorGroup</TD><TD>TQPalette</TD></TR>
+<TR><TD>TQBrush</TD><TD>TQWidget::FocusPolicy</TD><TD>DCOPRef</TD></TR>
+<TR><TD>TQVariant</TD><TD>TQDate</TD><TD>TQTime</TD></TR>
+<TR><TD>TQDateTime</TD><TD>TQImage</TD><TD>TQKeySequence</TD></TR>
+<TR><TD>TQPen</TD><TD>TQPicture</TD><TD>TQPointArray</TD></TR>
+<TR><TD>TQValueList&lt;DCOPRef&gt;</TD><TD>TQValueList&lt;TQCString&gt;</TD><TD>TQMap&lt;TQCString,DCOPRef&gt;</TD></TR>
+<TR><TD>TQMap&lt;TQCString,DCOPRef&gt;</TD><TD></TD><TD></TD></TR>
</table>
<p>
Data conversion between C++ and Python types is done transparently. The integer types
map to Python int or Python long, the decimal types to Python double. A Python string
-can be used for any argument that requires a QString or QCString (return types will
-always be the Qt object type). The QValueList types take or return a Python list of the
-indicated object. The QMap types take or return a Python dict with the first type as
+can be used for any argument that requires a TQString or TQCString (return types will
+always be the Qt object type). The TQValueList types take or return a Python list of the
+indicated object. The TQMap types take or return a Python dict with the first type as
the key and the second type as data. All other types use the same object type in
-Python and Qt (for instance, QPoint or QStringList).
+Python and Qt (for instance, TQPoint or TQStringList).
</p>
<p>
It's possible to add support for more types in the future. To be added, a type requires
-a pair of overloaded QDataStream operators ("&lt;&lt;" and "&gt;&gt;"). Types must also
+a pair of overloaded TQDataStream operators ("&lt;&lt;" and "&gt;&gt;"). Types must also
exist in the libs that PyQt and PyKDE support - types specific to applications (like
konqueror) cannot be supported at this time.
</p>
@@ -251,8 +251,8 @@ handle the packing and unpacking details automatically behind the scenes.
</p>
<p>
The dcop_add and dcop_next functions are available in the PyKDE kdecore module (they
-may be relocated to a different module in the future). They use a QDataStream to operate
-on a QByteArray. The QByteArray can be thought of as a stack (a FIFO stack though) -
+may be relocated to a different module in the future). They use a TQDataStream to operate
+on a TQByteArray. The TQByteArray can be thought of as a stack (a FIFO stack though) -
dcop_add pushes objects onto the stack, dcop_next pops objects off the stack. The first
object popped off will be the first object pushed on, etc.
</p>
@@ -263,26 +263,26 @@ different argument counts. Here are some examples:
<TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%">
<TR><TD><PRE CLASS="PROGRAMLISTING">
from kdecore import dcop_add, dcop_next
-from qt import QByteArray, QDataStream, IO_ReadOnly, IO_WriteOnly, QString,\
- QCString, QValueList&lt;QCString&gt;
+from qt import TQByteArray, TQDataStream, IO_ReadOnly, IO_WriteOnly, TQString,\
+ TQCString, TQValueList&lt;TQCString&gt;
from dcopext import numericTypes, stringTypes
-b = QByteArray ()
-s = QDataStream (b, IO_WriteOnly)
+b = TQByteArray ()
+s = TQDataStream (b, IO_WriteOnly)
i = 6
d = 3.14
-t = QString ("Hello, World")
-x = QCString ("One")
-y = QCString ("Two")
-z = QCString ("Three")
+t = TQString ("Hello, World")
+x = TQCString ("One")
+y = TQCString ("Two")
+z = TQCString ("Three")
l = [x, y, z]
dcop_add (s, i, "long")
dcop_add (s, d, "double")
dcop_add (s, t)
dcop_add (s, x)
-dcop_add (s, l, "QValueList&lt;QCString&gt;")
+dcop_add (s, l, "TQValueList&lt;TQCString&gt;")
</PRE></TD></TR></TABLE>
<p>
@@ -291,11 +291,11 @@ specify the C++ type of the object - that's because Python has only 3 basic nume
types, while C++ has at least 10 basic numeric types plus variations via typedefs.
</p>
<p>
-Also, the QValueList (and QMap - not shown) type needs a qualifier - a Python list
+Also, the TQValueList (and TQMap - not shown) type needs a qualifier - a Python list
type doesn't know (or care) what the type of its elements is.
</p>
<p>
-Other types (QString, QCString) are uniquely typed, so no modifier is needed.
+Other types (TQString, TQCString) are uniquely typed, so no modifier is needed.
</p>
<p>
While it may change in the future, dcop_add right now retains the variable argument lists.
@@ -312,7 +312,7 @@ if atype in numericTypes:
dcop_add (s, value, atype)
elif atype in stringTypes and isinstance (value, str):
dcop_add (s, eval ("%s('%s')" % (atype, value)))
-elif atype.startswith ("QMap") or atype.startswith ("QValueList"):
+elif atype.startswith ("TQMap") or atype.startswith ("TQValueList"):
dcop_add (params, value, atype)
else:
dcop_add (s, value)
@@ -321,25 +321,25 @@ else:
<p>
At least in DCOP related applications, all of the necessary type information is always
easily available. The first if clause above processes numeric types; the second if
-clause allows you to use Python strings in place of Qt's QString or QCString types; the
-third if clause handles QValueList and QMap based types; the else clause handles
+clause allows you to use Python strings in place of Qt's TQString or TQCString types; the
+third if clause handles TQValueList and TQMap based types; the else clause handles
everything else.
</p>
<p>
-Unpacking a QByteArray is simpler - dcop_next always takes a QDataStream instance and
+Unpacking a TQByteArray is simpler - dcop_next always takes a TQDataStream instance and
a type name string. The code below assumes the same set of imports as above:
</p>
<TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%">
<TR><TD><PRE CLASS="PROGRAMLISTING">
-# b is a QByteArray to be unpacked
-s = QDataStream (b, IO_ReadOnly)
+# b is a TQByteArray to be unpacked
+s = TQDataStream (b, IO_ReadOnly)
i1 = dcop_next (s, "long")
d1 = dcop_next (s, "double")
-t1 = dcop_next (s, "QString")
-x1 = dcop_next (s, "QCString")
-l1 = dcop_next (s, "QValueList&lt;QCString&gt;")
+t1 = dcop_next (s, "TQString")
+x1 = dcop_next (s, "TQCString")
+l1 = dcop_next (s, "TQValueList&lt;TQCString&gt;")
</PRE></TD></TR></TABLE>
<p>