From f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Sat, 3 Dec 2011 11:05:10 -0600 Subject: Second part of prior commit --- .../docs/tdemultimedia/artsbuilder/porting.docbook | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 tde-i18n-it/docs/tdemultimedia/artsbuilder/porting.docbook (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 new file mode 100644 index 00000000000..f0b84a21d73 --- /dev/null +++ b/tde-i18n-it/docs/tdemultimedia/artsbuilder/porting.docbook @@ -0,0 +1,52 @@ + + + +Il porting delle applicazioni su &arts; + + +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;. + +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. + + + + +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