summaryrefslogtreecommitdiffstats
path: root/tde-i18n-sv/docs/tdemultimedia
diff options
context:
space:
mode:
authorMichele Calgaro <michele.calgaro@yahoo.it>2023-10-13 18:02:18 +0900
committerMichele Calgaro <michele.calgaro@yahoo.it>2023-10-13 18:02:18 +0900
commit241e0082f7b9ccadaeed0ef43a1c9ebb9b4fe840 (patch)
tree327c08329d5c5910cc155d3982f2a481eeaf5307 /tde-i18n-sv/docs/tdemultimedia
parent1ae0d186c941b1e1cdaae488038195ba86d89dbb (diff)
downloadtde-i18n-241e0082f7b9ccadaeed0ef43a1c9ebb9b4fe840.tar.gz
tde-i18n-241e0082f7b9ccadaeed0ef43a1c9ebb9b4fe840.zip
Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version
Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>
Diffstat (limited to 'tde-i18n-sv/docs/tdemultimedia')
-rw-r--r--tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook2
-rw-r--r--tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook2
2 files changed, 2 insertions, 2 deletions
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:
<para>ä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). </para>
<para>Den motsvarande C++ terminologin skulle vara <programlisting>
- QWidget* w;
+ TQWidget* w;
w-&gt;show();
</programlisting> 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. </para>
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 {
<para>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. </para>
-<para>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 <classname>QString</classname>, <classname>QRect</classname>, <classname>QPixmap</classname>, <classname>QCString</classname>, .... 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 <classname>QString</classname>,... 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. </para>
+<para>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 <classname>TQString</classname>, <classname>QRect</classname>, <classname>QPixmap</classname>, <classname>QCString</classname>, .... 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 <classname>TQString</classname>,... 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. </para>
<para>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). </para>