diff --git a/doc/artsbuilder/detail.docbook b/doc/artsbuilder/detail.docbook index 34adf3d1..37d5e328 100644 --- a/doc/artsbuilder/detail.docbook +++ b/doc/artsbuilder/detail.docbook @@ -1415,7 +1415,7 @@ once you assigned something else (like a null reference). The equivalent C++ terms would be - QWidget* w; + TQWidget* w; w->show(); diff --git a/doc/artsbuilder/mcop.docbook b/doc/artsbuilder/mcop.docbook index 4b1d6615..ca4a195a 100644 --- a/doc/artsbuilder/mcop.docbook +++ b/doc/artsbuilder/mcop.docbook @@ -2197,11 +2197,11 @@ that, I am certainly proven wrong. While I do know that &DCOP; basically doesn't know about the data types it sends, so that you could use &DCOP; without using &Qt;, look at how it is used in daily &kde; usage: people send types like -QString, QRect, +TQString, QRect, QPixmap, QCString, ..., around. These use &Qt;-serialization. So if somebody choose to support &DCOP; in a GNOME program, they would either have to claim to use -QString,... types (although they don't do so), +TQString,... types (although they don't do so), and emulate the way &Qt; does the streaming, or they would send other string, pixmap and rect types around, and thus not be interoperable. diff --git a/noatun/modules/making_plugins b/noatun/modules/making_plugins index cb921cc2..0134b321 100644 --- a/noatun/modules/making_plugins +++ b/noatun/modules/making_plugins @@ -6,7 +6,7 @@ You're free to use the net plugin as a base, I've licensed it under the public domain, so you can relicense it however you wish (preferably not GPL, though :) -Remember that QObject must derive first. +Remember that TQObject must derive first. Do a "return this;" in the PlayList *playlist() const; function, if your class is a playlist, otherwise, don't even override that function.