diff options
Diffstat (limited to 'tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder')
| -rw-r--r-- | tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/detail.docbook | 2 | ||||
| -rw-r--r-- | tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/mcop.docbook | 2 |
2 files changed, 2 insertions, 2 deletions
diff --git a/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/detail.docbook b/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/detail.docbook index c740d2b09e7..5689f303b23 100644 --- a/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/detail.docbook +++ b/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/detail.docbook @@ -752,7 +752,7 @@ public: <para>é um pouco diferente que dereferenciar um ponteiro NULL. Você não disse o objeto o que ele é, e agora você tenta usá-lo. A suposição aqui é que você deseja ter uma nova instância local do objeto Synth::PLAY. É claro que você deve ter desejado algo como isso (como criar o objeto em algum outro local, ou usar um objeto remoto existente). No entanto, é um atalho conveniente para criar objetos. A criação relaxada não funcionará uma vez que você atribua algo mais (como uma referência null). </para> <para>O equivalente em termos de C++ deve ser <programlisting> - QWidget* w; + TQWidget* w; w->show(); </programlisting> que obviamente em C++ocasiona falhas de segmentação. Assim isto é diferente aqui. Esta criação relaxada é um truque especialmente porque não é necessário que uma implementação para sua interface exista. </para> diff --git a/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/mcop.docbook index 611806c4c23..8433f9b1560 100644 --- a/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/mcop.docbook +++ b/tde-i18n-pt_BR/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 de fluxo do &Qt;, iria conduzir facilmente a que a plataforma se tornasse apenas para o &Qt; (ou apenas para o &kde;). Quer dizer: tão logo se veja os GNOMEs começando a usar o &DCOP;, também, ou algo do gênero, provavelmente eu estarei 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 é usado no uso 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; em um programa do GNOME, ele teria de afirmar que usava os tipos <classname>QString</classname>,... (ainda que não o faça, de fato) 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 retângulos, o que deixaria de ser interoperável. </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 é usado no uso 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; em um programa do GNOME, ele teria de afirmar que usava os tipos <classname>TQString</classname>,... (ainda que não o faça, de fato) 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 retângulos, o que deixaria de ser interoperável. </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 operacional proprietário conhecido). </para> |