From 241e0082f7b9ccadaeed0ef43a1c9ebb9b4fe840 Mon Sep 17 00:00:00 2001 From: Michele Calgaro Date: Fri, 13 Oct 2023 18:02:18 +0900 Subject: Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version Signed-off-by: Michele Calgaro --- tde-i18n-de/docs/tdemultimedia/artsbuilder/detail.docbook | 2 +- tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'tde-i18n-de/docs/tdemultimedia') diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/detail.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/detail.docbook index dc874b70bbe..075e1770ee9 100644 --- a/tde-i18n-de/docs/tdemultimedia/artsbuilder/detail.docbook +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/detail.docbook @@ -562,7 +562,7 @@ public: Arts::Synth_PLAY p; string s = p.toString(); is something different than dereferencing a NULL pointer. You didn't tell the object at all what it is, and now you try to use it. The guess here is that you want to have a new local instance of a Arts::Synth_PLAY object. Of course you might have wanted something else (like creating the object somewhere else, or using an existing remote object). However, it is a convenient short cut to creating objects. Lazy creation will not work once you assigned something else (like a null reference). The equivalent C++ terms would be - QWidget* w; + TQWidget* w; w->show(); which obviously in C++ just plain segfaults. So this is different here. This lazy creation is tricky especially as not necessarily an implementation exists for your interface. For instance, consider an abstract thing like a Arts::PlayObject. There are certainly concrete PlayObjects like those for playing mp3s or wavs, but Arts::PlayObject po; diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook index 9fdef47ba8e..c29898adaf9 100644 --- a/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook @@ -866,7 +866,7 @@ struct TypeDef { There is no need to base a middleware for multimedia on &Qt;. Deciding so, and using all that nice &Qt;-streaming and stuff, will easily lead to the middleware becoming a &Qt;-only (or rather &kde;-only) thing. I mean: as soon as I'll see the GNOMEs using &DCOP;, too, or something like 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, QPixmap, QCString, ..., around. These use &Qt;-serialization. So if somebody choose to support &DCOP; in a GNOME program, he would either have to claim to use QString,... types (although he doesn't do so), and emulate the way &Qt; does the streaming, or he would send other string, pixmap and rect types around, and thus not be interoperable. + 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 TQString, QRect, QPixmap, QCString, ..., around. These use &Qt;-serialization. So if somebody choose to support &DCOP; in a GNOME program, he would either have to claim to use TQString,... types (although he doesn't do so), and emulate the way &Qt; does the streaming, or he would send other string, pixmap and rect types around, and thus not be interoperable. Well, whatever. &arts; was always intended to work with or without &kde;, with or without &Qt;, with or without X11, and maybe even with or without &Linux; (and I have even no problems with people who port it to a popular non-free operating systems). -- cgit v1.2.1