You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
53 lines
2.7 KiB
53 lines
2.7 KiB
13 years ago
|
<!-- <?xml version="1.0" ?>
|
||
|
|
<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
|
||
|
|
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
|
||
|
|
>Il porting delle applicazioni su &arts;</title>
|
||
|
|
|
||
|
|
<sect1 id="using-artsdsp">
|
||
|
|
<title
|
||
|
|
>Uso di &artsdsp;</title>
|
||
|
|
|
||
|
|
<para
|
||
|
|
>L'utility &artsdsp;, <link linkend="artsdsp"
|
||
|
|
>descritta precedentemente</link
|
||
|
|
>, 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, (<application
|
||
|
|
>esd</application
|
||
|
|
>) funzioneranno nella maggior parte dei casi lanciando <application
|
||
|
|
>esd</application
|
||
|
|
> sotto &artsdsp;. </para>
|
||
|
|
|
||
|
|
<para
|
||
|
|
>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;. </para>
|
||
|
|
|
||
|
|
<para
|
||
|
|
>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. </para>
|
||
|
|
|
||
|
|
</sect1>
|
||
|
|
|
||
|
|
<sect1 id="adding-native-arts-support">
|
||
|
|
<title
|
||
|
|
>Aggiungere il supporto nativo per &arts;</title>
|
||
|
|
|
||
|
|
<para
|
||
|
|
>Quando usi &arts;, hai un certo numero di <link linkend="arts-apis"
|
||
|
|
><acronym
|
||
|
|
>API</acronym
|
||
|
|
></link
|
||
|
|
> 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'<acronym
|
||
|
|
>API</acronym
|
||
|
|
> richieste, e se essa è scritta in C++. Nella maggior parte dei casi la scelta dovrebbe essere relativamente ovvia, basandosi sulle caratteristiche richieste. </para>
|
||
|
|
|
||
|
|
<para
|
||
|
|
>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'<acronym
|
||
|
|
>API</acronym
|
||
|
|
> 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;. </para>
|
||
|
|
|
||
|
|
</sect1>
|
||
|
|
|
||
|
|
</chapter>
|
||
|
|
|