From 203ba231d0276943aae36111f9ec1e949f3c6a4c Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Sat, 3 Dec 2011 22:23:44 -0600 Subject: Initial TQt conversion --- doc/dcopext.html | 104 +++++++++++++++++++++++++++---------------------------- 1 file changed, 52 insertions(+), 52 deletions(-) (limited to 'doc/dcopext.html') diff --git a/doc/dcopext.html b/doc/dcopext.html index a42e9ed..a22fa6f 100644 --- a/doc/dcopext.html +++ b/doc/dcopext.html @@ -33,10 +33,10 @@ reliable to run

What Extensions?

There are three basic extensions added to PyKDE that are not part of KDE itself:
-
Packing/Unpacking QByteArrays
+
Packing/Unpacking TQByteArrays
-DCOP passes data between applications using QByteArrays. QByteArrays can be difficult to -pack or unpack using PyQt or PyKDE, so PyKDE has additional methods (dcop_add and dcop_next) +DCOP passes data between applications using TQByteArrays. TQByteArrays can be difficult to +pack or unpack using PyTQt or PyKDE, so PyKDE has additional methods (dcop_add and dcop_next) to make these operations simpler in Python
Client Extensions
@@ -48,27 +48,27 @@ Python classes, and the method being called looks to the programmer like a Pytho
DCOP Enabling (Export) Extensions
Another set of extensions makes it trivial to expose an application's methods via DCOP to -other applications. All that is required is to subclass a pre-written Python class and +other applications. All that is retquired is to subclass a pre-written Python class and provide a list of the methods to expose, along with a method signature listing the name of the method, it's return type, and the the types of its arguments.

-The methods for packing/unpacking QByteArrays are available to the programmer, but are +The methods for packing/unpacking TQByteArrays are available to the programmer, but are primarily used transparently by the other PyKDE DCOP extensions. The client and export extensions are two Python modules that are included and installed as part of PyKDE.

Calling DCOP Methods

-Accessing a DCOP method in another application requires 3 pieces of information: the name of +Accessing a DCOP method in another application retquires 3 pieces of information: the name of the application to be accessed, the name of the DCOP object which holds the method to be called, and the name of the method itself.

Collection the Information

-The easiest way to collect the required information is to use the kdcop application that +The easiest way to collect the retquired information is to use the kdcop application that comes with PyKDE. kdcop is graphical application that looks like the image shown.

@@ -159,31 +159,31 @@ The DCOP extensions will support any of the following C++ data types: unsigned intunsigned longuchar ushsortuintulong Q_INT32pid_tfloat -doubleQStringQStringList -QCStringKURLKURL::List -QSizeQRectQRegion -QFontQCursorQPixmap -QColorQColorGroupQPalette -QBrushQWidget::FocusPolicyDCOPRef -QVariantQDateQTime -QDateTimeQImageQKeySequence -QPenQPictureQPointArray -QValueList<DCOPRef>QValueList<QCString>QMap<QCString,DCOPRef> -QMap<QCString,DCOPRef> +doubleTQStringTQStringList +TQCStringKURLKURL::List +TQSizeTQRectTQRegion +TQFontTQCursorTQPixmap +TQColorTQColorGroupTQPalette +TQBrushTQWidget::FocusPolicyDCOPRef +TQVariantTQDateTQTime +TQDateTimeTQImageTQKeySequence +TQPenTQPictureTQPointArray +TQValueList<DCOPRef>TQValueList<TQCString>TQMap<TQCString,DCOPRef> +TQMap<TQCString,DCOPRef>

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 retquires a TQString or TQCString (return types will +always be the TQt 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 TQt (for instance, TQPoint or TQStringList).

-It's possible to add support for more types in the future. To be added, a type requires -a pair of overloaded QDataStream operators ("<<" and ">>"). Types must also -exist in the libs that PyQt and PyKDE support - types specific to applications (like +It's possible to add support for more types in the future. To be added, a type retquires +a pair of overloaded TQDataStream operators ("<<" and ">>"). Types must also +exist in the libs that PyTQt and PyKDE support - types specific to applications (like konqueror) cannot be supported at this time.

Other Extension Features

@@ -241,18 +241,18 @@ care of everything else, including the "functions()" method which applications ( kdcop, for example) can call to find out which methods are available and their return and argument types. You can have multiple instances of DCOPExObj in a program. All of the data types listed above are supported transparently - you don't have to pack or -unpack QByteArrays. +unpack TQByteArrays.

-

Packing and Unpacking QByteArrays

+

Packing and Unpacking TQByteArrays

NOTE: It isn't necessary to use the dcop_add and dcop_next functions or worry about -QByteArrays at all when using dcopext or dcopexport as shown above. Those modules +TQByteArrays at all when using dcopext or dcopexport as shown above. Those modules handle the packing and unpacking details automatically behind the scenes.

The dcop_add and dcop_next functions are available in the PyKDE tdecore 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.

@@ -263,26 +263,26 @@ different argument counts. Here are some examples: 
 from tdecore import dcop_add, dcop_next
-from qt import QByteArray, QDataStream, IO_ReadOnly, IO_WriteOnly, QString,\
-    QCString, QValueList<QCString>
+from qt import TQByteArray, TQDataStream, IO_ReadOnly, IO_WriteOnly, TQString,\
+    TQCString, TQValueList<TQCString>
 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<QCString>")
+dcop_add (s, l, "TQValueList<TQCString>")

@@ -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.

-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.

-Other types (QString, QCString) are uniquely typed, so no modifier is needed. +Other types (TQString, TQCString) are uniquely typed, so no modifier is needed.

While it may change in the future, dcop_add right now retains the variable argument lists. @@ -306,13 +306,13 @@ You can handle this in your own code easily if you import "numericTypes" and 
 # atype is the type of the argument being processed (as a string)
-# value is the object being packed into the QByteArray
+# value is the object being packed into the TQByteArray
 
 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:
 

 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 TQt's TQString or TQCString types; the
+third if clause handles TQValueList and TQMap based types; the else clause handles 
 everything else.
 

 

-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:
 

 

 
 
-# 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<QCString>")
+t1 = dcop_next (s, "TQString")
+x1 = dcop_next (s, "TQCString")
+l1 = dcop_next (s, "TQValueList<TQCString>")
 
 

 

@@ -355,7 +355,7 @@ section above.
 

 The code for dcopext and dcopexport is based on pydcop.py and pcop.cpp written by Torben Weis
 and Julian Rockey. It's available in the dcoppython/ section of the kde-bindings source code,
-and can be used to implement DCOP communication without using PyQt or PyKDE.
+and can be used to implement DCOP communication without using PyTQt or PyKDE.
 

 
 

-- 
cgit v1.2.1