diff options
Diffstat (limited to 'tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/porting.docbook')
| -rw-r--r-- | tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/porting.docbook | 42 |
1 files changed, 10 insertions, 32 deletions
diff --git a/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/porting.docbook b/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/porting.docbook index f245e6459e2..381bf73d7e8 100644 --- a/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/porting.docbook +++ b/tde-i18n-pt_BR/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 --> <chapter id="porting"> -<title ->Portando Aplicativos para o &arts;</title> +<title>Portando Aplicativos para o &arts;</title> <sect1 id="using-artsdsp"> -<title ->Usando o &artsdsp;</title> +<title>Usando o &artsdsp;</title> -<para ->O utilitário &artsdsp;, <link linkend="artsdsp" ->descrito anteriormente</link ->, possibilita que a maioria dos aplicativos antigos que se comunicavam diretamente com os dispositivos de áudio, funcionem corretamente com o &arts;. Aplicativos escritos para usar o Enlightenment Sound Daemon (<application ->esd</application ->) irão funcionar na maioria dos casos, rodando o <application ->esd</application -> com o &artsdsp;. </para> +<para>O utilitário &artsdsp;, <link linkend="artsdsp">descrito anteriormente</link>, possibilita que a maioria dos aplicativos antigos que se comunicavam diretamente com os dispositivos de áudio, funcionem corretamente com o &arts;. Aplicativos escritos para usar o Enlightenment Sound Daemon (<application>esd</application>) irão funcionar na maioria dos casos, rodando o <application>esd</application> com o &artsdsp;. </para> -<para ->Isto faz com que seja encurtado o caminho para portar aplicativos existentes para o &kde;. No entanto, isto não possibilita que esses aplicativos tirem vantagem do potencial do &arts;, como utilizar módulos e e usar outros fluxos de multimídia que não sejam de áudio digital. Se o aplicativo necessita de recursos mais sofisticados do que simplesmente reproduzir arquivos de som, normalmente faz mais sentido adicionar suporte nativo para o &arts; ao aplicativo. </para> +<para>Isto faz com que seja encurtado o caminho para portar aplicativos existentes para o &kde;. No entanto, isto não possibilita que esses aplicativos tirem vantagem do potencial do &arts;, como utilizar módulos e e usar outros fluxos de multimídia que não sejam de áudio digital. Se o aplicativo necessita de recursos mais sofisticados do que simplesmente reproduzir arquivos de som, normalmente faz mais sentido adicionar suporte nativo para o &arts; ao aplicativo. </para> -<para ->Usando o &arts; o seu aplicativo não precisa realizar muito trabalho -- ele pode se apoiar nas funções do &arts; para tratar de coisas como codecs para diferentes formatos de mídia e controle do hardware de som. </para> +<para>Usando o &arts; o seu aplicativo não precisa realizar muito trabalho -- ele pode se apoiar nas funções do &arts; para tratar de coisas como codecs para diferentes formatos de mídia e controle do hardware de som. </para> </sect1> <sect1 id="adding-native-arts-support"> -<title ->Adicionando Suporte Nativo ao &arts;</title> - -<para ->Ao usar o &arts;, você terá inúmeras <link linkend="arts-apis" -><acronym ->API</acronym ->s</link -> para escolher. A decisão de qual usar depende de uma série de fatores, incluindo o tipo de mídia a ser usado (som, &MIDI;, &CD; áudio, &etc;), os recursos requeridos da <acronym ->API</acronym ->, e quando é escrito em C++. Na maioria dos casos a escolha refere-se obviamente aos recursos requeridos. </para> - -<para ->Para portabilidade entre plataformas, aplicativos que necessitam rodar em ambientes que não sejam o &kde; não confie no &arts; pelo menos até o momento. Usar paradigma de plug-ins é uma boa escolha para suportar diferentes ambientes de multimídia. Fazendo uma <acronym ->API</acronym -> de plug-ins aberta e documentada (especiamente para aplicativos de código fechado) oferece a vantagem de que outras pessoas além dos desenvolvedores do aplicativo podem implementar um plug-in para o &arts;. </para> +<title>Adicionando Suporte Nativo ao &arts;</title> + +<para>Ao usar o &arts;, você terá inúmeras <link linkend="arts-apis"><acronym>API</acronym>s</link> para escolher. A decisão de qual usar depende de uma série de fatores, incluindo o tipo de mídia a ser usado (som, &MIDI;, &CD; áudio, &etc;), os recursos requeridos da <acronym>API</acronym>, e quando é escrito em C++. Na maioria dos casos a escolha refere-se obviamente aos recursos requeridos. </para> + +<para>Para portabilidade entre plataformas, aplicativos que necessitam rodar em ambientes que não sejam o &kde; não confie no &arts; pelo menos até o momento. Usar paradigma de plug-ins é uma boa escolha para suportar diferentes ambientes de multimídia. Fazendo uma <acronym>API</acronym> de plug-ins aberta e documentada (especiamente para aplicativos de código fechado) oferece a vantagem de que outras pessoas além dos desenvolvedores do aplicativo podem implementar um plug-in para o &arts;. </para> </sect1> |