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-it/docs/tdemultimedia/artsbuilder/porting.docbook') diff --git a/tde-i18n-it/docs/tdemultimedia/artsbuilder/porting.docbook b/tde-i18n-it/docs/tdemultimedia/artsbuilder/porting.docbook index f0b84a21d73..018f7a92af9 100644 --- a/tde-i18n-it/docs/tdemultimedia/artsbuilder/porting.docbook +++ b/tde-i18n-it/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 --> -Il porting delle applicazioni su &arts; +Il porting delle applicazioni su &arts; -Uso di &artsdsp; +Uso di &artsdsp; -L'utility &artsdsp;, descritta precedentemente, permette alla maggior parte delle vecchie applicazioni sonore che parlano direttamente ai dispositivi audio di funzionare correttamente sotto &arts;. Anche le applicazioni scritte per l'Enlightenment Sound Daemon, (esd) funzioneranno nella maggior parte dei casi lanciando esd sotto &artsdsp;. +L'utility &artsdsp;, descritta precedentemente, permette alla maggior parte delle vecchie applicazioni sonore che parlano direttamente ai dispositivi audio di funzionare correttamente sotto &arts;. Anche le applicazioni scritte per l'Enlightenment Sound Daemon, (esd) funzioneranno nella maggior parte dei casi lanciando esd sotto &artsdsp;. -Questa è una buona soluzione a breve termine per fare il porting delle applicazioni esistenti su &kde;. Comunque, non permette all'applicazione di sfruttare direttamente tutte le potenzialità di &arts;, come utilizzare moduli e flussi multimediali diversi dall'audio digitale. Se l'applicazione va oltre la semplice riproduzione di file sonori, è solitamente una buona idea aggiungere ad essa il supporto nativo per &arts;. +Questa è una buona soluzione a breve termine per fare il porting delle applicazioni esistenti su &kde;. Comunque, non permette all'applicazione di sfruttare direttamente tutte le potenzialità di &arts;, come utilizzare moduli e flussi multimediali diversi dall'audio digitale. Se l'applicazione va oltre la semplice riproduzione di file sonori, è solitamente una buona idea aggiungere ad essa il supporto nativo per &arts;. -Utilizzare &arts; vuole anche dire che l'applicazione non dovrà compiere più tanto lavoro: può sfruttare le funzioni di &arts; per gestire cose complicate come codec per formati di media differenti ed il controllo dell'hardware sonoro. +Utilizzare &arts; vuole anche dire che l'applicazione non dovrà compiere più tanto lavoro: può sfruttare le funzioni di &arts; per gestire cose complicate come codec per formati di media differenti ed il controllo dell'hardware sonoro. -Aggiungere il supporto nativo per &arts; - -Quando usi &arts;, hai un certo numero di API diverse tra cui scegliere. La decisione di quale utilizzare dipende da un certo numero di fattori, come il tipo di streaming media che vuoi utilizzare (suono, &MIDI;, &CD; audio, &etc;), le caratteristiche dell'API richieste, e se essa è scritta in C++. Nella maggior parte dei casi la scelta dovrebbe essere relativamente ovvia, basandosi sulle caratteristiche richieste. - -Per la portabilità multi-piattaforma, le applicazioni che hanno bisogno di girare su ambienti diversi da &kde; non possono fare affidamento sulla presenza di &arts;. L'utilizzo del paradigma a plug-in è un buon modo per supportare ambienti multimediali differenti. Rendere l'API del plug-in aperta e documentata (specialmente per le applicazioni a codice sorgente chiuso) ha anche il vantaggio di permettere a qualcuno che non sia lo sviluppatore dell'applicazione di implementare un plug-in per &arts;. +Aggiungere il supporto nativo per &arts; + +Quando usi &arts;, hai un certo numero di API diverse tra cui scegliere. La decisione di quale utilizzare dipende da un certo numero di fattori, come il tipo di streaming media che vuoi utilizzare (suono, &MIDI;, &CD; audio, &etc;), le caratteristiche dell'API richieste, e se essa è scritta in C++. Nella maggior parte dei casi la scelta dovrebbe essere relativamente ovvia, basandosi sulle caratteristiche richieste. + +Per la portabilità multi-piattaforma, le applicazioni che hanno bisogno di girare su ambienti diversi da &kde; non possono fare affidamento sulla presenza di &arts;. L'utilizzo del paradigma a plug-in è un buon modo per supportare ambienti multimediali differenti. Rendere l'API del plug-in aperta e documentata (specialmente per le applicazioni a codice sorgente chiuso) ha anche il vantaggio di permettere a qualcuno che non sia lo sviluppatore dell'applicazione di implementare un plug-in per &arts;. -- cgit v1.2.1