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-sv/docs/tdemultimedia/artsbuilder/detail.docbook | 2 +- tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'tde-i18n-sv/docs/tdemultimedia') diff --git a/tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook b/tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook index a82b531cd83..99bdf7fe2f9 100644 --- a/tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook +++ b/tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook @@ -752,7 +752,7 @@ public: är något annorlunda än att följa en NULL-pekare. Du talade inte alls om för objektet vad det är, och nu försöker du använda det. Gissningen här är att du vill ha en ny lokal instans av ett Arts::Synth_PLAY-objekt. Du kan förstås ha velat göra något annat (som att skapa objektet någon annanstans, eller använda ett befintligt fjärrobjekt). Det är i alla fall en bekväm genväg för att skapa objekt. Att skapa ett objekt när det först används fungerar inte när du väl har tilldelat det något annat (som en null-referens). Den motsvarande C++ terminologin skulle vara - QWidget* w; + TQWidget* w; w->show(); som naturligtvis helt enkelt ger ett segmenteringsfel i C++. Så detta är annorlunda här. Det här sättet att skapa objekt är knepigt, eftersom det inte är nödvändigt att det finns en implementering för ditt gränssnitt. diff --git a/tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook index bf79aebb367..38453d7da04 100644 --- a/tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook +++ b/tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook @@ -1219,7 +1219,7 @@ struct TypeDef { Det finns ingen anledning att basera mellanprogram för multimedia på &Qt;. Genom att bestämma sig för det, och använda allt de där trevliga &Qt;-strömmarna och andra saker, kan det lätt leda till att mellanprogram bara blir en sak för &Qt;-(eller i själva verket bara &kde;). Jag menar att om jag någonsin ser att GNOME också använder &DCOP;, eller någonting liknande, är det förstås bevisat att jag har fel. -Fastän jag vet att &DCOP; i grunden inte känner till de datatyper som det skickar, så att man skulle kunna använda &DCOP; utan &Qt;, se hur det används i daglig &kde;-användning: man skickar runt typer som QString, QRect, QPixmap, QCString, .... De här använder &Qt;:s-serialisering. Så om någon väljer att stöda &DCOP; i ett GNOME-program, måste han antingen ange att han använder QString,... typer (även om han inte gör det), och emulera sättet som &Qt; använder för strömmar, eller så skulle han skicka runt andra sträng-, pixmap- och rect-typer, och på så sätt ändå inte kunna fungera ihop med &kde;-program. +Fastän jag vet att &DCOP; i grunden inte känner till de datatyper som det skickar, så att man skulle kunna använda &DCOP; utan &Qt;, se hur det används i daglig &kde;-användning: man skickar runt typer som TQString, QRect, QPixmap, QCString, .... De här använder &Qt;:s-serialisering. Så om någon väljer att stöda &DCOP; i ett GNOME-program, måste han antingen ange att han använder TQString,... typer (även om han inte gör det), och emulera sättet som &Qt; använder för strömmar, eller så skulle han skicka runt andra sträng-, pixmap- och rect-typer, och på så sätt ändå inte kunna fungera ihop med &kde;-program. Nå, hur som helst var alltid &arts; avsett att fungera med eller utan &kde;, med eller utan &Qt;, med eller utan X11, och kanske till och med med eller utan &Linux; (och jag har inte ens några invändningar mot personer som anpassar det till operativsystem som inte är fria). -- cgit v1.2.1