|
|
|
@ -48,7 +48,7 @@ Python classes, and the method being called looks to the programmer like a Pytho
|
|
|
|
|
<dt>DCOP Enabling (Export) Extensions</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
Another set of extensions makes it trivial to expose an application's methods via DCOP to
|
|
|
|
|
other applications. All that is retquired is to subclass a pre-written Python class and
|
|
|
|
|
other applications. All that is required 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.
|
|
|
|
|
</dd>
|
|
|
|
@ -61,14 +61,14 @@ are two Python modules that are included and installed as part of PyKDE.
|
|
|
|
|
|
|
|
|
|
<h2>Calling DCOP Methods</h2>
|
|
|
|
|
<p>
|
|
|
|
|
Accessing a DCOP method in another application retquires 3 pieces of information: the name of
|
|
|
|
|
Accessing a DCOP method in another application requires 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.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Collection the Information</h3>
|
|
|
|
|
<p>
|
|
|
|
|
The easiest way to collect the retquired information is to use the kdcop application that
|
|
|
|
|
The easiest way to collect the required information is to use the kdcop application that
|
|
|
|
|
comes with PyKDE. kdcop is graphical application that looks like the image shown.
|
|
|
|
|
</p>
|
|
|
|
|
<IMG src="images/kdcop1.png" align="middle" border="0">
|
|
|
|
@ -174,14 +174,14 @@ The DCOP extensions will support any of the following C++ data types:
|
|
|
|
|
<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 retquires a TQString or TQCString (return types will
|
|
|
|
|
can be used for any argument that requires 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 TQt (for instance, TQPoint or TQStringList).
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
It's possible to add support for more types in the future. To be added, a type retquires
|
|
|
|
|
It's possible to add support for more types in the future. To be added, a type requires
|
|
|
|
|
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.
|
|
|
|
|