From e5e8e3221561c92ace9e485a3b8778da1e4b5fbb Mon Sep 17 00:00:00 2001 From: Michele Calgaro Date: Sat, 23 Sep 2023 12:44:34 +0900 Subject: [PATCH] Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version Signed-off-by: Michele Calgaro (cherry picked from commit 938578ffc3e80f59646041c2483985f1d70692f6) --- doc/artsbuilder/detail.docbook | 2 +- doc/artsbuilder/mcop.docbook | 4 ++-- noatun/modules/making_plugins | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) 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.