From 0b8ca6637be94f7814cafa7d01ad4699672ff336 Mon Sep 17 00:00:00 2001 From: Darrell Anderson Date: Tue, 21 Jan 2014 22:06:48 -0600 Subject: Beautify docbook files --- .../docs/tdemultimedia/artsbuilder/porting.docbook | 42 ++++++---------------- 1 file changed, 10 insertions(+), 32 deletions(-) (limited to 'tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook') diff --git a/tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook b/tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook index 03834e67b4c..398873f991c 100644 --- a/tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook +++ b/tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook @@ -4,47 +4,25 @@ To validate or process this file as a standalone document, uncomment this prolog. Be sure to comment it out again when you are done --> -Passar as Aplicações para o &arts; +Passar as Aplicações para o &arts; -Usar o &artsdsp; +Usar o &artsdsp; -O utilitário &artsdsp;, descrito anteriormente, permite à maioria das aplicações de som legadas que falem directamente com os dispositivos de áudio, funcionarem convenientemente com o &arts;. As aplicações que foram criadas para usar o Enlightenment Sound Daemon (esd) irão também funcionar na maioria dos casos, se for executado o esd sobre o &artsdsp;. +O utilitário &artsdsp;, descrito anteriormente, permite à maioria das aplicações de som legadas que falem directamente com os dispositivos de áudio, funcionarem convenientemente com o &arts;. As aplicações que foram criadas para usar o Enlightenment Sound Daemon (esd) irão também funcionar na maioria dos casos, se for executado o esd sobre o &artsdsp;. -Isto possibilita uma solução a curto prazo para passar as aplicações existentes para o &kde;. Todavia, não permite que a aplicação tire directamente partido de todas as potencialidades do &arts;, como a utilização dos módulos e das sequências multimédia que não sejam apenas áudio digital. Se a aplicação necessitar de algo mais do que a reprodução de ficheiros de som, normalmente fará sentido adicionar o suporte nativo para o &arts; na aplicação. +Isto possibilita uma solução a curto prazo para passar as aplicações existentes para o &kde;. Todavia, não permite que a aplicação tire directamente partido de todas as potencialidades do &arts;, como a utilização dos módulos e das sequências multimédia que não sejam apenas áudio digital. Se a aplicação necessitar de algo mais do que a reprodução de ficheiros de som, normalmente fará sentido adicionar o suporte nativo para o &arts; na aplicação. -Ao usar o &arts; significa também que a aplicação não terá assim muito trabalho -- poderá remeter as funções para o &arts;, de modo a resolver alguns problemas, como por exemplo os codificadores para lidar com diferentes formatos multimédia e controlar o 'hardware' de som. +Ao usar o &arts; significa também que a aplicação não terá assim muito trabalho -- poderá remeter as funções para o &arts;, de modo a resolver alguns problemas, como por exemplo os codificadores para lidar com diferentes formatos multimédia e controlar o 'hardware' de som. -Adicionar o suporte nativo do &arts; - -Ao usar o &arts;, você tem um conjunto de APIs diferentes por onde escolher. A decisão de qual usar depende de um conjunto de factores, como o tipo de conteúdos multimédia a usar (som, &MIDI;, &CD; áudio, &etc;), as funcionalidades necessárias da API, e se é escrito em C++. Na maioria dos casos, a escolha deverá ser relativamente óbvia com base nas funcionalidades pedidas. - -Para uma portabilidade entre plataformas, as aplicações que precisem de correr noutros ambientes que não sejam o &kde;, não poderão confiar na presença do &arts;. Se usar o paradigma dos 'plugins' terá uma boa forma de suportar vários ambiente multimédia. Se tornar a API de 'plugins' aberta e documentada (especialmente para as aplicações com código fechado), terá também a vantagem de permitir que alguém que não o programador da aplicação implemente um 'plugin' do &arts;. +Adicionar o suporte nativo do &arts; + +Ao usar o &arts;, você tem um conjunto de APIs diferentes por onde escolher. A decisão de qual usar depende de um conjunto de factores, como o tipo de conteúdos multimédia a usar (som, &MIDI;, &CD; áudio, &etc;), as funcionalidades necessárias da API, e se é escrito em C++. Na maioria dos casos, a escolha deverá ser relativamente óbvia com base nas funcionalidades pedidas. + +Para uma portabilidade entre plataformas, as aplicações que precisem de correr noutros ambientes que não sejam o &kde;, não poderão confiar na presença do &arts;. Se usar o paradigma dos 'plugins' terá uma boa forma de suportar vários ambiente multimédia. Se tornar a API de 'plugins' aberta e documentada (especialmente para as aplicações com código fechado), terá também a vantagem de permitir que alguém que não o programador da aplicação implemente um 'plugin' do &arts;. -- cgit v1.2.1