diff options
Diffstat (limited to 'tde-i18n-sv/docs/tdemultimedia/artsbuilder')
| -rw-r--r-- | tde-i18n-sv/docs/tdemultimedia/artsbuilder/detail.docbook | 2 | ||||
| -rw-r--r-- | tde-i18n-sv/docs/tdemultimedia/artsbuilder/mcop.docbook | 2 |
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->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> |