|
|
|
<HTML
|
|
|
|
><HEAD
|
|
|
|
><TITLE
|
|
|
|
>General Limitations</TITLE
|
|
|
|
><META
|
|
|
|
NAME="GENERATOR"
|
|
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
|
|
REL="HOME"
|
|
|
|
TITLE="Python Bindings for KDE (PyKDE-3.16.0)"
|
|
|
|
HREF="index.html"><LINK
|
|
|
|
REL="PREVIOUS"
|
|
|
|
TITLE="Python Bindings for KDE (PyKDE-3.16.0)"
|
|
|
|
HREF="index.html"><LINK
|
|
|
|
REL="NEXT"
|
|
|
|
TITLE="Signal and Slot Support"
|
|
|
|
HREF="signal.html"></HEAD
|
|
|
|
><BODY
|
|
|
|
CLASS="SECT1"
|
|
|
|
><DIV
|
|
|
|
CLASS="NAVHEADER"
|
|
|
|
><TABLE
|
|
|
|
SUMMARY="Header navigation table"
|
|
|
|
WIDTH="100%"
|
|
|
|
BORDER="0"
|
|
|
|
CELLPADDING="0"
|
|
|
|
CELLSPACING="0"
|
|
|
|
><TR
|
|
|
|
><TH
|
|
|
|
COLSPAN="3"
|
|
|
|
ALIGN="center"
|
|
|
|
>Python Bindings for KDE (PyKDE-3.3.16.0)</TH
|
|
|
|
></TR
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
WIDTH="10%"
|
|
|
|
ALIGN="left"
|
|
|
|
VALIGN="bottom"
|
|
|
|
><A
|
|
|
|
HREF="dcopext.html"
|
|
|
|
ACCESSKEY="P"
|
|
|
|
>Prev</A
|
|
|
|
></TD
|
|
|
|
><TD
|
|
|
|
WIDTH="80%"
|
|
|
|
ALIGN="center"
|
|
|
|
VALIGN="bottom"
|
|
|
|
></TD
|
|
|
|
><TD
|
|
|
|
WIDTH="10%"
|
|
|
|
ALIGN="right"
|
|
|
|
VALIGN="bottom"
|
|
|
|
><A
|
|
|
|
HREF="signal.html"
|
|
|
|
ACCESSKEY="N"
|
|
|
|
>Next</A
|
|
|
|
></TD
|
|
|
|
></TR
|
|
|
|
></TABLE
|
|
|
|
><HR
|
|
|
|
ALIGN="LEFT"
|
|
|
|
WIDTH="100%"></DIV
|
|
|
|
><DIV
|
|
|
|
CLASS="SECT1"
|
|
|
|
><H1
|
|
|
|
CLASS="SECT1"
|
|
|
|
><A
|
|
|
|
NAME="AEN28"
|
|
|
|
></A
|
|
|
|
>General Limitations</H1
|
|
|
|
><DIV
|
|
|
|
CLASS="SECT2"
|
|
|
|
><H2
|
|
|
|
CLASS="SECT2"
|
|
|
|
><A
|
|
|
|
NAME="AEN30"
|
|
|
|
></A
|
|
|
|
>Python Strings, TQt Strings and Unicode</H2
|
|
|
|
><P
|
|
|
|
>Unicode support was added to TQt in v2.0 and to Python in v1.6. In TQt, Unicode
|
|
|
|
support is implemented using the <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> class. It is
|
|
|
|
important to understand that <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
>s, Python string objects
|
|
|
|
and Python Unicode objects are all different but conversions between them are
|
|
|
|
automatic in many cases and easy to achieve manually when needed.</P
|
|
|
|
><P
|
|
|
|
>Whenever PyKDE expects a <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> as a function argument, a
|
|
|
|
Python string object or a Python Unicode object can be provided instead, and
|
|
|
|
PyKDE will do the necessary conversion automatically.</P
|
|
|
|
><P
|
|
|
|
>You may also manually convert Python string and Unicode objects to
|
|
|
|
<TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
>s by using the <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> constructor
|
|
|
|
as demonstrated in the following code fragment.</P
|
|
|
|
><TABLE
|
|
|
|
BORDER="0"
|
|
|
|
BGCOLOR="#E0E0E0"
|
|
|
|
WIDTH="100%"
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
><PRE
|
|
|
|
CLASS="PROGRAMLISTING"
|
|
|
|
>qs1 = TQString('Converted Python string object')
|
|
|
|
qs2 = TQString(u'Converted Python Unicode object')</PRE
|
|
|
|
></TD
|
|
|
|
></TR
|
|
|
|
></TABLE
|
|
|
|
><P
|
|
|
|
>In order to convert a <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> to a Python string object use
|
|
|
|
the Python <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>str()</TT
|
|
|
|
> function. Applying
|
|
|
|
<TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>str()</TT
|
|
|
|
> to a null <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> and an empty
|
|
|
|
<TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> both result in an empty Python string object.</P
|
|
|
|
><P
|
|
|
|
>In order to convert a <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> to a Python Unicode object use
|
|
|
|
the Python <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>unicode()</TT
|
|
|
|
> function. Applying
|
|
|
|
<TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>unicode()</TT
|
|
|
|
> to a null <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> and an empty
|
|
|
|
<TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQString</TT
|
|
|
|
> both result in an empty Python Unicode object.</P
|
|
|
|
></DIV
|
|
|
|
><DIV
|
|
|
|
CLASS="SECT2"
|
|
|
|
><H2
|
|
|
|
CLASS="SECT2"
|
|
|
|
><A
|
|
|
|
NAME="AEN53"
|
|
|
|
></A
|
|
|
|
>Access to Protected Member Functions</H2
|
|
|
|
><P
|
|
|
|
>When an instance of a C++ class is not created from Python it is not possible
|
|
|
|
to access the protected member functions, or emit the signals, of that
|
|
|
|
instance. Attempts to do so will raise a Python exception. Also, any Python
|
|
|
|
methods corresponding to the instance's virtual member functions will never be
|
|
|
|
called.</P
|
|
|
|
></DIV
|
|
|
|
><DIV
|
|
|
|
CLASS="SECT2"
|
|
|
|
><H2
|
|
|
|
CLASS="SECT2"
|
|
|
|
><A
|
|
|
|
NAME="AEN56"
|
|
|
|
></A
|
|
|
|
>Garbage Collection</H2
|
|
|
|
><P
|
|
|
|
>C++ does not garbage collect unreferenced class instances, whereas Python does.
|
|
|
|
In the following C++ fragment both colours exist even though the first can no
|
|
|
|
longer be referenced from within the program:</P
|
|
|
|
><TABLE
|
|
|
|
BORDER="0"
|
|
|
|
BGCOLOR="#E0E0E0"
|
|
|
|
WIDTH="100%"
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
><PRE
|
|
|
|
CLASS="PROGRAMLISTING"
|
|
|
|
>c = TQColor();
|
|
|
|
c = TQColor();</PRE
|
|
|
|
></TD
|
|
|
|
></TR
|
|
|
|
></TABLE
|
|
|
|
><P
|
|
|
|
>In the corresponding Python fragment, the first colour is destroyed when
|
|
|
|
the second is assigned to <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>c</TT
|
|
|
|
>:</P
|
|
|
|
><TABLE
|
|
|
|
BORDER="0"
|
|
|
|
BGCOLOR="#E0E0E0"
|
|
|
|
WIDTH="100%"
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
><PRE
|
|
|
|
CLASS="PROGRAMLISTING"
|
|
|
|
>c = TQColor()
|
|
|
|
c = TQColor()</PRE
|
|
|
|
></TD
|
|
|
|
></TR
|
|
|
|
></TABLE
|
|
|
|
><P
|
|
|
|
>In Python, each colour must be assigned to different names. Typically this
|
|
|
|
is done within class definitions, so the code fragment would be something like:</P
|
|
|
|
><TABLE
|
|
|
|
BORDER="0"
|
|
|
|
BGCOLOR="#E0E0E0"
|
|
|
|
WIDTH="100%"
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
><PRE
|
|
|
|
CLASS="PROGRAMLISTING"
|
|
|
|
>self.c1 = TQColor()
|
|
|
|
self.c2 = TQColor()</PRE
|
|
|
|
></TD
|
|
|
|
></TR
|
|
|
|
></TABLE
|
|
|
|
><P
|
|
|
|
>Sometimes a TQt class instance will maintain a pointer to another instance and
|
|
|
|
will eventually call the destructor of that second instance. The most common
|
|
|
|
example is that a <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQObject</TT
|
|
|
|
> (and any of its sub-classes) keeps
|
|
|
|
pointers to its children and will automatically call their destructors. In
|
|
|
|
these cases, the corresponding Python object will also keep a reference to the
|
|
|
|
corresponding child objects.</P
|
|
|
|
><P
|
|
|
|
>So, in the following Python fragment, the first <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQLabel</TT
|
|
|
|
> is
|
|
|
|
not destroyed when the second is assigned to <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>l</TT
|
|
|
|
> because the
|
|
|
|
parent <TT
|
|
|
|
CLASS="LITERAL"
|
|
|
|
>TQWidget</TT
|
|
|
|
> still has a reference to it.</P
|
|
|
|
><TABLE
|
|
|
|
BORDER="0"
|
|
|
|
BGCOLOR="#E0E0E0"
|
|
|
|
WIDTH="100%"
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
><PRE
|
|
|
|
CLASS="PROGRAMLISTING"
|
|
|
|
>p = TQWidget()
|
|
|
|
l = TQLabel('First label',p)
|
|
|
|
l = TQLabel('Second label',p)</PRE
|
|
|
|
></TD
|
|
|
|
></TR
|
|
|
|
></TABLE
|
|
|
|
></DIV
|
|
|
|
><DIV
|
|
|
|
CLASS="SECT2"
|
|
|
|
><H2
|
|
|
|
CLASS="SECT2"
|
|
|
|
><A
|
|
|
|
NAME="AEN72"
|
|
|
|
></A
|
|
|
|
>C++ Variables</H2
|
|
|
|
><P
|
|
|
|
>Access to C++ variables is supported. They are accessed as Python instance
|
|
|
|
variables. For example:</P
|
|
|
|
><TABLE
|
|
|
|
BORDER="0"
|
|
|
|
BGCOLOR="#E0E0E0"
|
|
|
|
WIDTH="100%"
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
><PRE
|
|
|
|
CLASS="PROGRAMLISTING"
|
|
|
|
>tab = TQTab()
|
|
|
|
tab.label = "First Tab"
|
|
|
|
tab.r = TQRect(10,10,75,30)</PRE
|
|
|
|
></TD
|
|
|
|
></TR
|
|
|
|
></TABLE
|
|
|
|
><P
|
|
|
|
>Global variables and static class variables are effectively read-only. They
|
|
|
|
can be assigned to, but the underlying C++ variable will not be changed. This
|
|
|
|
may change in the future.</P
|
|
|
|
><P
|
|
|
|
>Access to protected C++ class variables is not supported. This may change in
|
|
|
|
the future.</P
|
|
|
|
></DIV
|
|
|
|
><DIV
|
|
|
|
CLASS="SECT2"
|
|
|
|
><H2
|
|
|
|
CLASS="SECT2"
|
|
|
|
><A
|
|
|
|
NAME="AEN78"
|
|
|
|
></A
|
|
|
|
>Multiple Inheritance</H2
|
|
|
|
><P
|
|
|
|
>It is not possible to define a new Python class that sub-classes from more than
|
|
|
|
one TQt class.</P
|
|
|
|
></DIV
|
|
|
|
></DIV>
|
|
|
|
|
|
|
|
<H2 CLASS="SECT2">tr() methods</H2>
|
|
|
|
<P>
|
|
|
|
In a normal TQt installation, every descendant of TQObject inherits two methods
|
|
|
|
(tr (const char *) and tr (const char *, const char *) from TQObject explicitly
|
|
|
|
and also overloads these methods via the moc mechanism (by defining Q_OBJECT
|
|
|
|
in the class declaration). KDE however is compiled with -DQT_NO_TRANSLATION,
|
|
|
|
which prevents moc from creating the overloading tr() methods, and also produces
|
|
|
|
side-effects with a normal TQt installation which was compiled without the
|
|
|
|
-DQT_NO_TRANSLATION switch.
|
|
|
|
</P>
|
|
|
|
<P>
|
|
|
|
PyKDE handles this situation by NOT providing tr() methods (either the inherited
|
|
|
|
methods from TQObject or the moc generated methods) for any KDE based TQObject
|
|
|
|
descendant. The tr() methods are static, so TQObject::tr () methods are available
|
|
|
|
via PyTQt, as are tr() methods for any PyTQt TQObject descendant. PyKDE's handling
|
|
|
|
of these methods has no effect on PyTQt.
|
|
|
|
</P>
|
|
|
|
<P>Instead of the tr() methods, KDE uses corresponding i18n() methods for translating.
|
|
|
|
These methods are available in the tdecore module of PyKDE. For compatibility with
|
|
|
|
KDE, you should use the i18n methods.
|
|
|
|
</P>
|
|
|
|
<H2>Socket classes</H2>
|
|
|
|
<P>
|
|
|
|
The following classes (introduced in KDE2.2.0) are NOT yet implemented:
|
|
|
|
</P>
|
|
|
|
<TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%">
|
|
|
|
<TR>
|
|
|
|
<TD>
|
|
|
|
<PRE CLASS="PROGRAMLISTING">
|
|
|
|
KAddressInfo
|
|
|
|
KExtendedSocket
|
|
|
|
KInetSocketAddress
|
|
|
|
KSocketAddress
|
|
|
|
KUnixSocketAddress
|
|
|
|
KSocks
|
|
|
|
</PRE>
|
|
|
|
</TD>
|
|
|
|
</TR>
|
|
|
|
</TABLE>
|
|
|
|
<P>
|
|
|
|
Most of their functionality already exists in the Python socket class or in the
|
|
|
|
KSocket class (tdecore module). These classes may be implemented at a future date
|
|
|
|
(they retquire support for C socket structures and careful handling to avoid buffer
|
|
|
|
overflow problems/exploits)
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<DIV
|
|
|
|
CLASS="NAVFOOTER"
|
|
|
|
><HR
|
|
|
|
ALIGN="LEFT"
|
|
|
|
WIDTH="100%"><TABLE
|
|
|
|
SUMMARY="Footer navigation table"
|
|
|
|
WIDTH="100%"
|
|
|
|
BORDER="0"
|
|
|
|
CELLPADDING="0"
|
|
|
|
CELLSPACING="0"
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
WIDTH="33%"
|
|
|
|
ALIGN="left"
|
|
|
|
VALIGN="top"
|
|
|
|
><A
|
|
|
|
HREF="dcopext.html"
|
|
|
|
ACCESSKEY="P"
|
|
|
|
>Prev</A
|
|
|
|
></TD
|
|
|
|
><TD
|
|
|
|
WIDTH="34%"
|
|
|
|
ALIGN="center"
|
|
|
|
VALIGN="top"
|
|
|
|
><A
|
|
|
|
HREF="index.html"
|
|
|
|
ACCESSKEY="H"
|
|
|
|
>Home</A
|
|
|
|
></TD
|
|
|
|
><TD
|
|
|
|
WIDTH="33%"
|
|
|
|
ALIGN="right"
|
|
|
|
VALIGN="top"
|
|
|
|
><A
|
|
|
|
HREF="signal.html"
|
|
|
|
ACCESSKEY="N"
|
|
|
|
>Next</A
|
|
|
|
></TD
|
|
|
|
></TR
|
|
|
|
><TR
|
|
|
|
><TD
|
|
|
|
WIDTH="33%"
|
|
|
|
ALIGN="left"
|
|
|
|
VALIGN="top"
|
|
|
|
>DCOP and Extensions</TD
|
|
|
|
><TD
|
|
|
|
WIDTH="34%"
|
|
|
|
ALIGN="center"
|
|
|
|
VALIGN="top"
|
|
|
|
> </TD
|
|
|
|
><TD
|
|
|
|
WIDTH="33%"
|
|
|
|
ALIGN="right"
|
|
|
|
VALIGN="top"
|
|
|
|
>Signal and Slot Support</TD
|
|
|
|
></TR
|
|
|
|
></TABLE
|
|
|
|
></DIV
|
|
|
|
></BODY
|
|
|
|
></HTML
|
|
|
|
>
|