Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version

Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>

2 files changed, 2 insertions, 2 deletions

diff --git a/tde-i18n-pt/docs/tdemultimedia/artsbuilder/detail.docbook b/tde-i18n-pt/docs/tdemultimedia/artsbuilder/detail.docbook
index f7742790bc1..6cd027b9d4d 100644
--- a/tde-i18n-pt/docs/tdemultimedia/artsbuilder/detail.docbook
+++ b/tde-i18n-pt/docs/tdemultimedia/artsbuilder/detail.docbook
@@ -753,7 +753,7 @@ public:
 <para>é algo diferente de fazer uma referência a um ponteiro NULL. Você não indicou ao objecto de todo o que ele é, e agora irá tentar usá-lo. A questão aqui é que você deseja ter uma instância local de um objecto Arts::Synth_PLAY. Claro que você poderá querer ter algo diferente (como criar o objecto noutro local qualquer, ou usar um objecto remoto existente). Contudo, é um atalho conveniente para criar objectos. A criação tardia não irá funcionar logo que tenha atribuído outra coisa qualquer (como por exemplo uma referência nula). </para>
 
 <para>Os termos equivalentes em C++ seriam <programlisting>
-   QWidget* janela;
+   TQWidget* janela;
    janela-&gt;show();
 </programlisting> o que obviamente, em C++, iria dar um estoiro garantido. Por isso, isto é diferente aqui. Esta criação tardia é enganadora, porque não quer dizer que exista necessariamente uma implementação para a sua interface. </para>
 
diff --git a/tde-i18n-pt/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-pt/docs/tdemultimedia/artsbuilder/mcop.docbook
index d8877326b2c..5718659868d 100644
--- a/tde-i18n-pt/docs/tdemultimedia/artsbuilder/mcop.docbook
+++ b/tde-i18n-pt/docs/tdemultimedia/artsbuilder/mcop.docbook
@@ -1219,7 +1219,7 @@ struct TypeDef {
 
 <para>Não existe necessidade de basear uma plataforma de multimédia no &Qt;. Ao decidir isso, e usando toda aquela serialização e outras funcionalidades giras do &Qt;, iria conduzir facilmente a que a plataforma se tornasse apenas para o &Qt; ou (para apenas para o &kde;). Quer dizer: assim que se vir que os GNOMEs comecem a usar o &DCOP;, também, ou algo do género, provavelmente o autor ficará errado. </para>
 
-<para>Enquanto se sabe que o &DCOP; basicamente não sabe nada sobre os tipos de dados que envia, de modo que você poderia usar o &DCOP; sem usar o &Qt;, veja como é que é usado na utilização do dia-a-dia do &kde;: as pessoas enviam tipos como o <classname>QString</classname>, o <classname>QRect</classname>, o <classname>QPixmap</classname>, o <classname>QCString</classname>, ..., de um lado para o outro. Estes usam a serialização do &Qt;. Por isso, se alguém optar por suportar o &DCOP; num programa do GNOME, ele teria de afirmar que usava os tipos <classname>QString</classname>,... (ainda que não o faça, de facto) e emular a forma como o &Qt; faz a transmissão, ou então teria de enviar outros tipos de cadeias de caracteres, imagens e rectângulos, o que deixaria de ter possibilidades de interoperabilidade. </para>
+<para>Enquanto se sabe que o &DCOP; basicamente não sabe nada sobre os tipos de dados que envia, de modo que você poderia usar o &DCOP; sem usar o &Qt;, veja como é que é usado na utilização do dia-a-dia do &kde;: as pessoas enviam tipos como o <classname>TQString</classname>, o <classname>QRect</classname>, o <classname>QPixmap</classname>, o <classname>QCString</classname>, ..., de um lado para o outro. Estes usam a serialização do &Qt;. Por isso, se alguém optar por suportar o &DCOP; num programa do GNOME, ele teria de afirmar que usava os tipos <classname>TQString</classname>,... (ainda que não o faça, de facto) e emular a forma como o &Qt; faz a transmissão, ou então teria de enviar outros tipos de cadeias de caracteres, imagens e rectângulos, o que deixaria de ter possibilidades de interoperabilidade. </para>
 
 <para>Bem, seja o que for, o &arts; pretendeu sempre funcionar com ou sem o &kde;, com ou sem o &Qt;, com ou sem o X11, e talvez com ou sem o &Linux; (e não há problema nenhum com as pessoas que o transpõem para um sistema operativo proprietário conhecido). </para>