diff options
Diffstat (limited to 'tde-i18n-es/docs/tdemultimedia/artsbuilder/mcop.docbook')
| -rw-r--r-- | tde-i18n-es/docs/tdemultimedia/artsbuilder/mcop.docbook | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/tde-i18n-es/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-es/docs/tdemultimedia/artsbuilder/mcop.docbook index 8bd7047154a..d6f49e67197 100644 --- a/tde-i18n-es/docs/tdemultimedia/artsbuilder/mcop.docbook +++ b/tde-i18n-es/docs/tdemultimedia/artsbuilder/mcop.docbook @@ -1219,7 +1219,7 @@ struct TypeDef { <para>No es necesario basar una plataforma multimedia en &Qt;. Una vez decidido ésto, y utilizando la serialización y otras funcionalidades de &Qt;, se podría concluir fácilmente en una plataforma solo-&Qt; (e incluso solo-&kde;). Quiero decir: tan pronto como vea a GNOME utilizando &DCOP;, o quizá algo similar, comprobaré si estaba equivocado. </para> -<para>Como &DCOP; no sabe nada sobre los tipos de datos que envía, podría utilizar &DCOP; sin utilizar &Qt;, veamos el uso diario que se hace de &kde;: la gente envía tipos como <classname>QString</classname>, <classname>QRect</classname>, <classname>QPixmap</classname>, <classname>QCString</classname>, ..., de un lado para otro. Esto utiliza la serialización &Qt;. Por eso si alguien elige soportar &DCOP; en un programa GNOME, debería utilizar tipos <classname>QString</classname>,... (aunque no lo haga de facto), y emular la forma en que &Qt; realiza la transmisión, o podría enviar otros tipos de cadena, imágenes y rectángulos, lo que dejaría de ser interoperativo. </para> +<para>Como &DCOP; no sabe nada sobre los tipos de datos que envía, podría utilizar &DCOP; sin utilizar &Qt;, veamos el uso diario que se hace de &kde;: la gente envía tipos como <classname>TQString</classname>, <classname>QRect</classname>, <classname>QPixmap</classname>, <classname>QCString</classname>, ..., de un lado para otro. Esto utiliza la serialización &Qt;. Por eso si alguien elige soportar &DCOP; en un programa GNOME, debería utilizar tipos <classname>TQString</classname>,... (aunque no lo haga de facto), y emular la forma en que &Qt; realiza la transmisión, o podría enviar otros tipos de cadena, imágenes y rectángulos, lo que dejaría de ser interoperativo. </para> <para>Bueno, sea como fuere, &arts; siempre intentó funcionar con o sin &kde;, con o sin &Qt;, con o sin X11, y quizá incluso con o sin &Linux; (y no ha habido problemas con la gente que lo ha portado a un popular sistema operativo no libre). </para> |