diff options
Diffstat (limited to 'python/pykde/doc/limits.html')
| -rw-r--r-- | python/pykde/doc/limits.html | 427 |
1 files changed, 0 insertions, 427 deletions
diff --git a/python/pykde/doc/limits.html b/python/pykde/doc/limits.html deleted file mode 100644 index d94cabcb..00000000 --- a/python/pykde/doc/limits.html +++ /dev/null @@ -1,427 +0,0 @@ -<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, Qt Strings and Unicode</H2 -><P ->Unicode support was added to Qt in v2.0 and to Python in v1.6. In Qt, 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 Qt 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 Qt class.</P -></DIV -></DIV> - -<H2 CLASS="SECT2">tr() methods</H2> -<P> -In a normal Qt 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 Qt 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 QObject -descendant. The tr() methods are static, so TQObject::tr () methods are available -via PyQt, as are tr() methods for any PyQt TQObject descendant. PyKDE's handling -of these methods has no effect on PyQt. -</P> -<P>Instead of the tr() methods, KDE uses corresponding i18n() methods for translating. -These methods are available in the kdecore 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 (kdecore module). These classes may be implemented at a future date -(they require 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 -> |