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/future.docbook | 320 +++++---------------- 1 file changed, 78 insertions(+), 242 deletions(-) (limited to 'tde-i18n-it/docs/tdemultimedia/artsbuilder/future.docbook') diff --git a/tde-i18n-it/docs/tdemultimedia/artsbuilder/future.docbook b/tde-i18n-it/docs/tdemultimedia/artsbuilder/future.docbook index 0b8931d27f2..a92bc45a45e 100644 --- a/tde-i18n-it/docs/tdemultimedia/artsbuilder/future.docbook +++ b/tde-i18n-it/docs/tdemultimedia/artsbuilder/future.docbook @@ -5,394 +5,230 @@ To validate or process this file as a standalone document, uncomment this prolog. Be sure to comment it out again when you are done --> -Lavoro futuro +Lavoro futuro -Questa sezione descrive il lavoro di &arts; in corso. Lo sviluppo procede velocemente, perciò queste informazioni potrebbe non essere aggiornate. Dovresti controllare il file della lista TODO e gli archivi della mailing list per vedere quale nuova funzionalità è prevista. Sentiti libero di partecipare al nuovo design e all'implementazione. +Questa sezione descrive il lavoro di &arts; in corso. Lo sviluppo procede velocemente, perciò queste informazioni potrebbe non essere aggiornate. Dovresti controllare il file della lista TODO e gli archivi della mailing list per vedere quale nuova funzionalità è prevista. Sentiti libero di partecipare al nuovo design e all'implementazione. -Questa è la bozza del documento che cerca di darti una panoramica di come le nuove tecnologie saranno integrate in &arts;. In particolare, riguarda quello che segue: +Questa è la bozza del documento che cerca di darti una panoramica di come le nuove tecnologie saranno integrate in &arts;. In particolare, riguarda quello che segue: -Come funzionano le interfacce. -Codec - decodificazione dei flussi mp3 o wav in un formato tale che possano essere usati come dati. -Video. -Threading. -Sincronizzazione. -Espansione dinamica/masquerading. -Composizione dinamica. -&GUI; -&MIDI; +Come funzionano le interfacce. +Codec - decodificazione dei flussi mp3 o wav in un formato tale che possano essere usati come dati. +Video. +Threading. +Sincronizzazione. +Espansione dinamica/masquerading. +Composizione dinamica. +&GUI; +&MIDI; -Questo è il lavoro in corso. Comunque, questo dovrebbe essere solo la base se vuoi vedere nuove tecnologie in &arts;. Dovrebbe darti un'idea generale di come questi problemi saranno indirizzati. Comunque sentiti libero di correggere qualsiasi cosa vedi qui. +Questo è il lavoro in corso. Comunque, questo dovrebbe essere solo la base se vuoi vedere nuove tecnologie in &arts;. Dovrebbe darti un'idea generale di come questi problemi saranno indirizzati. Comunque sentiti libero di correggere qualsiasi cosa vedi qui. -Ciò che userà la tecnologia &arts; (quindi per favore coordina i tuoi sforzi): +Ciò che userà la tecnologia &arts; (quindi per favore coordina i tuoi sforzi): -KPhone (voce su IP) +KPhone (voce su IP) -&noatun; (lettore video / audio) +&noatun; (lettore video / audio) -&artscontrol; (programma di controllo del server sonoro per visualizzatori) +&artscontrol; (programma di controllo del server sonoro per visualizzatori) -Brahms (sequenziatore musicale) +Brahms (sequenziatore musicale) -Kaiman (&kde;2 media player - compatibilità con kmedia2) +Kaiman (&kde;2 media player - compatibilità con kmedia2) -mpglib/kmpg (tecnologia di riproduzione audio e video mpg) +mpglib/kmpg (tecnologia di riproduzione audio e video mpg) -SDL (direct media layer per giochi non ancora avviato ma forse funziona) +SDL (direct media layer per giochi non ancora avviato ma forse funziona) -electric ears (l'autore mi ha contattato - lo stato è sconosciuto) +electric ears (l'autore mi ha contattato - lo stato è sconosciuto) -Come funzionano le Interfacce +Come funzionano le Interfacce -Le interfacce &MCOP; sono la base del concetto di &arts;. Sono l'equivalente della rete alle classi C++. Quando possibile dovresti orientare il tuo design verso le interfacce. Le interfacce consistono in quattro parti: +Le interfacce &MCOP; sono la base del concetto di &arts;. Sono l'equivalente della rete alle classi C++. Quando possibile dovresti orientare il tuo design verso le interfacce. Le interfacce consistono in quattro parti: -Flussi sincroni -Flussi asincroni -Metodi -Attributi +Flussi sincroni +Flussi asincroni +Metodi +Attributi -Questi possono essere mescolati come vuoi. Le nuove tecnologie dovrebbero essere definite in termini di interfacce. Leggiti le sezioni sui flussi asincroni e sui flussi sincroni, così come le interfacce di KMedia2, che sono un buon esempio su come funzionano queste cose - -Le interfacce sono specificate nel codice .idl ed eseguite tramite il compilatore mcopidl. Ricava la classe Nomeinterfaccia_impl per implementarle e usa REGISTER_IMPLEMENTATION(Interfacename_impl) per inserire le implementazioni del tuo oggetto nel sistema dell'oggetto &MCOP;. +Questi possono essere mescolati come vuoi. Le nuove tecnologie dovrebbero essere definite in termini di interfacce. Leggiti le sezioni sui flussi asincroni e sui flussi sincroni, così come le interfacce di KMedia2, che sono un buon esempio su come funzionano queste cose + +Le interfacce sono specificate nel codice .idl ed eseguite tramite il compilatore mcopidl. Ricava la classe Nomeinterfaccia_impl per implementarle e usa REGISTER_IMPLEMENTATION(Interfacename_impl) per inserire le implementazioni del tuo oggetto nel sistema dell'oggetto &MCOP;. -Codec - Decodificazione dei dati +Codec - Decodificazione dei dati -Le interfacce kmedia2 ti permettono di ignorare quei file wav, mp3 e qualsiasi cosa sia composta da flussi di dati. Invece, implementano solamente i metodi per eseguirli. +Le interfacce kmedia2 ti permettono di ignorare quei file wav, mp3 e qualsiasi cosa sia composta da flussi di dati. Invece, implementano solamente i metodi per eseguirli. -In questo modo puoi scrivere una procedura di caricamento wave in modo da eseguire i file wave (come PlayObject), ma nessun altro può usare il tuo codice. +In questo modo puoi scrivere una procedura di caricamento wave in modo da eseguire i file wave (come PlayObject), ma nessun altro può usare il tuo codice. -I flussi asincroni potrebbero essere l'alternativa. Definisci un'interfaccia che ti permetta di passare i blocchi di dati in entrata e di ottenere i blocchi di dati in uscita. Questo sembra simile a quello di &MCOP;: +I flussi asincroni potrebbero essere l'alternativa. Definisci un'interfaccia che ti permetta di passare i blocchi di dati in entrata e di ottenere i blocchi di dati in uscita. Questo sembra simile a quello di &MCOP;: -interface Codec { +interface Codec { in async byte stream indata; out async byte stream outdata; }; -Naturalmente i codec possono anche fornire attributi per emettere dati aggiuntivi, come le informazioni di formattazione. +Naturalmente i codec possono anche fornire attributi per emettere dati aggiuntivi, come le informazioni di formattazione. -interface ByteAudioCodec { +interface ByteAudioCodec { in async byte stream indata; out async byte stream outdata; readonly attribute samplingRate, bits, channels; }; -Questo ByteAudioCodec per esempio potrebbe essere connesso ad un oggetto ByteStreamToAudio, per fare un vero audio float. +Questo ByteAudioCodec per esempio potrebbe essere connesso ad un oggetto ByteStreamToAudio, per fare un vero audio float. -Naturalmente altri tipi di codec possono coinvolgere l'emissione diretta di dati video, come per esempio +Naturalmente altri tipi di codec possono coinvolgere l'emissione diretta di dati video, come per esempio -interface VideoCodec { +interface VideoCodec { in async byte stream indata; out video stream outdata; /* nota: i flussi video ancora non esistono */ }; -Molto probabilmente il concetto di un codec dovrebbe essere impiegato piuttosto che nel modo tu sai come riprodurre e io no come per esempio WavPlayObject attualmente fa. Tuttavia qualcuno ha bisogno di sedersi e di fare qualche esperimento prima che un API possa essere finito. +Molto probabilmente il concetto di un codec dovrebbe essere impiegato piuttosto che nel modo tu sai come riprodurre e io no come per esempio WavPlayObject attualmente fa. Tuttavia qualcuno ha bisogno di sedersi e di fare qualche esperimento prima che un API possa essere finito. -Video +Video -La mia idea è di fornire video come flussi asincroni di qualche tipo di dati nativi di &MCOP; che contengono immagini. Questo tipo di dati deve ancora essere creato. Facendo questo le estensioni che si occupano di immagini video potrebbero essere connesse allo stesso modo delle estensioni audio. +La mia idea è di fornire video come flussi asincroni di qualche tipo di dati nativi di &MCOP; che contengono immagini. Questo tipo di dati deve ancora essere creato. Facendo questo le estensioni che si occupano di immagini video potrebbero essere connesse allo stesso modo delle estensioni audio. -Ci sono alcune cose importanti da non tralasciare, cioè: +Ci sono alcune cose importanti da non tralasciare, cioè: -Ci sono spazi di colori RGB e YUV. +Ci sono spazi di colori RGB e YUV. -Il formato dovrebbe essere in qualche modo aggiunto al flusso. +Il formato dovrebbe essere in qualche modo aggiunto al flusso. -La sincronizzazione è importante. +La sincronizzazione è importante. -La mia idea è di lasciare la possibilità di reimplementare la classe VideoFrame in modo che possa memorizzare le cose in un segmento di memoria condivisa. Così facendo anche il flusso video tra processi differenti sarebbe possibile senza troppi problemi. +La mia idea è di lasciare la possibilità di reimplementare la classe VideoFrame in modo che possa memorizzare le cose in un segmento di memoria condivisa. Così facendo anche il flusso video tra processi differenti sarebbe possibile senza troppi problemi. -Comunque, la situazione standard per il video è che le cose sono nello stesso processo, dalla decodifica al rendering. +Comunque, la situazione standard per il video è che le cose sono nello stesso processo, dalla decodifica al rendering. -Ho fatto una primitiva implementazione di flusso video, che puoi scaricare qui . Questa avrebbe bisogno di essere integrata in &MCOP; dopo alcuni esperimenti. +Ho fatto una primitiva implementazione di flusso video, che puoi scaricare qui . Questa avrebbe bisogno di essere integrata in &MCOP; dopo alcuni esperimenti. -Dovrebbe essere fornita una componente rendering che supporti XMITSHM (con RGB e YUV), Martin Vogt mi ha detto che sta lavorando su qualcosa del genere. +Dovrebbe essere fornita una componente rendering che supporti XMITSHM (con RGB e YUV), Martin Vogt mi ha detto che sta lavorando su qualcosa del genere. -Threading +Threading -Generalmente, &MCOP; è processato tutto in uno. Forse per il video non saremo più in grado di aggirare il threading. Ok. Ci sono alcune cose che dovrebbero essere trattate con attenzione: +Generalmente, &MCOP; è processato tutto in uno. Forse per il video non saremo più in grado di aggirare il threading. Ok. Ci sono alcune cose che dovrebbero essere trattate con attenzione: -SmartWrappers - non sono sicuri da thread a causa del conteggio dei riferimenti non sicuro e altro. +SmartWrappers - non sono sicuri da thread a causa del conteggio dei riferimenti non sicuro e altro. -Dispatcher / I/O - anche non sicuri da thread. +Dispatcher / I/O - anche non sicuri da thread. -Tuttavia, quello che potrei immaginare è di rendere i moduli selezionati sicuri da thread, sia per i flussi sincroni che asincroni. In modo che, con un sistema consapevole dello scorrere dei thread, potresti programmare lo scorrere del segnale su due o più processi. Questo aiuterebbe molto anche l'audio di cose su un multiprocessore. +Tuttavia, quello che potrei immaginare è di rendere i moduli selezionati sicuri da thread, sia per i flussi sincroni che asincroni. In modo che, con un sistema consapevole dello scorrere dei thread, potresti programmare lo scorrere del segnale su due o più processi. Questo aiuterebbe molto anche l'audio di cose su un multiprocessore. -Ecco come dovrebbe funzionare: +Ecco come dovrebbe funzionare: -Il sistema di flusso decide quali moduli dovrebbero calcolare cosa - ovvero: +Il sistema di flusso decide quali moduli dovrebbero calcolare cosa - ovvero: - frame video (con il metodo process_indata) - flussi audio asincroni (calculateBlock) - altri flussi asincroni, principalmente flussi byte + frame video (con il metodo process_indata) + flussi audio asincroni (calculateBlock) + altri flussi asincroni, principalmente flussi byte -I moduli possono calcolare queste cose nei propri processi. Per l'audio, è utile riusare i processi (il render ⪚ su quattro processi per quattro processori, non importa se 100 moduli sono in esecuzione). Per la decompressione dei video e dei byte, sarebbe più semplice avere un'implementazione di blocco in un proprio processo, che è sincronizzato contro il resto di &MCOP; dal sistema di flusso. +I moduli possono calcolare queste cose nei propri processi. Per l'audio, è utile riusare i processi (il render ⪚ su quattro processi per quattro processori, non importa se 100 moduli sono in esecuzione). Per la decompressione dei video e dei byte, sarebbe più semplice avere un'implementazione di blocco in un proprio processo, che è sincronizzato contro il resto di &MCOP; dal sistema di flusso. -I moduli potrebbero non usare le funzionalità &MCOP; (come chiamate remote) durante un'operazione processata. +I moduli potrebbero non usare le funzionalità &MCOP; (come chiamate remote) durante un'operazione processata. -Sincronizzazione +Sincronizzazione -Il video e il &MIDI; (e l'audio) potrebbero richiedere la sincronizzazione. Sostanzialmente, si tratta dell'ora. L'idea che ho è di attaccare delle ore ai flussi asincroni, aggiungendone uno a ogni pacchetto. Se invii due frame video, semplicemente ne fai due pacchetti (sono grossi comunque), in modo che puoi avere due diversi valori dell'ora. +Il video e il &MIDI; (e l'audio) potrebbero richiedere la sincronizzazione. Sostanzialmente, si tratta dell'ora. L'idea che ho è di attaccare delle ore ai flussi asincroni, aggiungendone uno a ogni pacchetto. Se invii due frame video, semplicemente ne fai due pacchetti (sono grossi comunque), in modo che puoi avere due diversi valori dell'ora. -L'audio dovrebbe implicitamente avere un'ora associata, dato che è sincrono. +L'audio dovrebbe implicitamente avere un'ora associata, dato che è sincrono. -Composizione dinamica +Composizione dinamica -È possibile dire: un effetto FX è composto di questi semplici moduli. FX dovrebbe sembrare un normale modulo &MCOP; (vedi masquerading), ma in realtà è composto di altri moduli. +È possibile dire: un effetto FX è composto di questi semplici moduli. FX dovrebbe sembrare un normale modulo &MCOP; (vedi masquerading), ma in realtà è composto di altri moduli. -Questo è richiesto per &arts-builder;. +Questo è richiesto per &arts-builder;. -&GUI; +&GUI; -Tutti i componenti della &GUI; saranno moduli &MCOP;. Dovrebbero avere attributi come grandezza, etichetta, colore, ... . Un compilatore RAD (&arts-builder;) dovrebbe essere in grado di comporli in modo visivo. +Tutti i componenti della &GUI; saranno moduli &MCOP;. Dovrebbero avere attributi come grandezza, etichetta, colore, ... . Un compilatore RAD (&arts-builder;) dovrebbe essere in grado di comporli in modo visivo. -La &GUI; dovrebbero essere salvabili, salvandone gli attributi. +La &GUI; dovrebbero essere salvabili, salvandone gli attributi. -&MIDI; +&MIDI; -Gli elementi &MIDI; vengono implementati come flussi asincroni. Ci sono due opzioni, una è usare le normali strutture &MCOP; per definire i caratteri e l'altra è di introdurre ancora caratteri personalizzati. +Gli elementi &MIDI; vengono implementati come flussi asincroni. Ci sono due opzioni, una è usare le normali strutture &MCOP; per definire i caratteri e l'altra è di introdurre ancora caratteri personalizzati. -Penso che le strutture normali potrebbero essere sufficienti, cioè: +Penso che le strutture normali potrebbero essere sufficienti, cioè: -struct MidiEvent { +struct MidiEvent { byte b1,b2,b3; sequence<byte> sysex; } -I flussi asincroni dovrebbero supportare i tipi di flusso personalizzati. +I flussi asincroni dovrebbero supportare i tipi di flusso personalizzati. -- cgit v1.2.1