Unicode support was added to TQt in v2.0 and to Python in v1.6. In TQt, Unicode support is implemented using the TQString class. It is important to understand that TQStrings, 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.
Whenever PyKDE expects a TQString 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.
You may also manually convert Python string and Unicode objects to TQStrings by using the TQString constructor as demonstrated in the following code fragment.
qs1 = TQString('Converted Python string object') qs2 = TQString(u'Converted Python Unicode object') |
In order to convert a TQString to a Python string object use the Python str() function. Applying str() to a null TQString and an empty TQString both result in an empty Python string object.
In order to convert a TQString to a Python Unicode object use the Python unicode() function. Applying unicode() to a null TQString and an empty TQString both result in an empty Python Unicode object.
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.
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:
c = TQColor(); c = TQColor(); |
In the corresponding Python fragment, the first colour is destroyed when the second is assigned to c:
c = TQColor() c = TQColor() |
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:
self.c1 = TQColor() self.c2 = TQColor() |
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 TQObject (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.
So, in the following Python fragment, the first TQLabel is not destroyed when the second is assigned to l because the parent TQWidget still has a reference to it.
p = TQWidget() l = TQLabel('First label',p) l = TQLabel('Second label',p) |
Access to C++ variables is supported. They are accessed as Python instance variables. For example:
tab = TQTab() tab.label = "First Tab" tab.r = TQRect(10,10,75,30) |
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.
Access to protected C++ class variables is not supported. This may change in the future.
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.
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.
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.
The following classes (introduced in KDE2.2.0) are NOT yet implemented:
KAddressInfo KExtendedSocket KInetSocketAddress KSocketAddress KUnixSocketAddress KSocks |
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)