IT/Non-code extensions it

From Apache OpenOffice Wiki
< IT(Redirected from Non-code extensions it)
Jump to: navigation, search
Progetto "Estensioni" per OOo

Si prega di consultare le
linee guida per l'uso del wiki
prima di contribuire.

Categorie:

Pagine:

Estensioni sul sito principale

Questo progetto in altre lingue:
DE EN ES FR OC


Estensioni di OOo: Principi basilari

OpenOffice.org è stato progettato per essere estendibile sin dalle sue origini. All'inizio ogni estensione era qualcosa che conteneva del codice (es: scritto in Java o OOo Basic). Era integrata all'interno di OOo dalla nostra tecnologia a componenti chiamata UNO, per questo il file contenente un'estensione era chiamata un "package UNO". Nel frattempo le estensioni di OOo si sono diffuse anche tra gli utenti e così abbiamo pensato che era giunta l'ora di cambiare un po' la terminologia. La seguente documentazione prende in considerazione questa motivazione. Cerca di evitare il termine tecnico "pacchetto UNO", dove possibile, così come lo scopo di questa documentazione è di fornire una vista generale e una spiegazione dei concetti basilari. Se vuoi imparare di più circa UNO puoi dare un'occhiata al wiki di UNO o alle pagine WEB del progetto UDK.

Il concetto di estensione di OpenOffice.org non è limitato al codice, permette anche di installare altre cose come template, autotext, ecc. utilizzando file singoli. Qui di seguito è riportata una breve spiegazione sul funzionamento di base di questa funzionalità. Questa documentazione è rivolta a utenti finali avanzati, amministratori e sviluppatori alle prime armi. Tutte le informazioni fornite qui descrivono cosa si può trovare in OpenOffice.org versione 2.0.4 o superiore. Le differenze con le versioni precedenti non sono elencate sebbene è menzionato in modo esplicito quando qualcosa è stato aggiunto nella versione 2.0.4 per la prima volta.

Se non sei interessato per nulla allo sviluppo, allora potresti volere saltare la sezione relativa al codice delle estensioni.

La sezione che tratta della gestione della configurazione fornisce alcune idee di come potresti utilizzare le estensioni di OOo per scopi di personalizzazione del prodotto.

Se sei soltanto interessato a conoscere come creare le "estensioni prive di codice" senza imparare realmente come funzionano, allora puoi passare direttamente alla sezione "Impostazione dei percorsi". Dovresti però almeno leggere questa sezione introduttiva.

Per favore spedisci eventuali considerazioni (in inglese) a Ooo-email.PNG. Nel caso hai accesso a questo wiki puoi certamente anche usare il tab "Discussion" presente in cima a questa pagina (meglio in inglese nella versione inglese della pagina).

Le estensioni di OOo sono più o meno archivi .ZIP con alcuni dati e metadati addizionali che descrivono il suo contenuto. Possono essere attivati utilizzando la funzionalità di gestione delle estensioni (Strumenti -> Gestione pacchetti) che permettono di installare le estensioni per l'utente corrente. Lo stesso risultato può essere ottenuto usando il programma a linea di comando "unopkg", che è posizionato nella directory dei programmi di OOo (in /usr/lib/openoffice/program sotto Debian e derivate). Questo programma permette anche di installare un'estensione per tutti gli utenti del sistema utilizzando il parametro "--shared".

Quando le estensioni sono installate il loro contenuto è copiato in una posizione privata ben definita all'interno dell'albero di directory di OOo: "share/uno_packages" (se l'installazione è globale) o "user/uno_packages" (se l'installazione è per il solo utente attuale). Con il termine "privata" si fa riferimento al fatto che non bisogna scrivere nessun codice che fa affidamento ad una particolare struttura di un'estensione scompressa, l'accesso ai file scompressi deve essere fatto tramite API definite che gestiscono questi dettagli per il chiamante. I file presente all'esterno della directory "uno_packages" non sono toccati per nulla, con la sola eccezione che può essere vista come un bug: le macro in Basic nelle estensioni di OOo hanno bisogno ancora di essere registrate in file xlc in una delle directory di "basic".

Le estensioni supportano l'installazione a caldo. Questo differisce, ad esempio da Firefox, dove occorre riavviare l'applicazione per avere le estensioni disponibili per l'uso. In OOo è possibile utilizzare le estensioni subito dopo l'installazione. C'è però una restrizione: è possibile che il codice di OOo tenga in cache quello che ha trovato al suo avvio o primo utilizzo di una determinata risorsa e quindi non vede un possibile cambiamento apportato dall'installazione dell'estensione. In questi casi è necessario per lo meno aprire una nuova finestra o documento di OOo o riavviare OOo. In molti casi questo comportamento può essere visto come un bug. Un esempio: in OOo 2.0.4 le estensioni dei template devono essere installate prima che la galleria sia usata per la prima volta.

Estensioni contenenti servizi di UNO (codice)

Se un'estensione di OOo contiene dei componenti di UNO scritti in Java, C++ o Python, allora questo componente deve pubblicare le sue funzionalità per diventare usabile per OOo. Nello sviluppo basato su UNO un insieme definito di funzionalità è chiamato "servizio". Un servizio è identificato e acceduto dai suoi nomi di servizi. Così un componente implementato come servizi deve dichiarare i propri identificativi al mondo. Attualmente tutti i componenti esportano una funzione che unopkg può chiamare per ottenere dal componente la scrittura delle informazioni necessarie all'interno di un file di registro del servizio che è creato e mantenuto all'interno della directory "uno_packages". Quando OOo utilizza il suo gestore dei servizi per vedere la disponibilità di servizi UNO non solo scansiona il registro dei servizi (services.rdb) nella sua directory di programma (contenente informazioni relative ai servizi interni), ma anche tutti i file di registro all'interno delle directory "uno_packages".

Certamente OOo può soltanto istanziare servizi di UNO dai loro nomi se li conosce. Questo è semplice per servizi che ne sostituiscono altri "interni" già esistenti, in questo caso OOo certamente già li conosce e li utilizza, ma la maggior parte dei componenti fornisce nuovi servizi e ci deve essere qualcosa d'altro che abilita OOo ad utilizzarli perché questi non sono di certo conosciuti durante la fase di compilazione. In questi casi i componenti di UNO devono fornire ulteriori informazioni a riguardo di quando un particolare servizio che implementano deve essere caricato. Le informazioni addizionali dei componenti sono passate a OOo mediante i file di configurazione.

Un esempio di questo è il componente di filtro di un documento dove l'informazione aggiuntiva che necessariamente deve essere fornita è (tra le altre cose) il tipo di file che il filtro è in grado di caricare. Un componente di filtro particolare può registrare sé stesso per essere in grado di caricare file nel formato Word Perfect. Così se un utente ha selezionato questo filtro per caricare un file, OOo troverà le informazioni registrate mediante ricerca di qualsiasi dato contenente il tipo di file desiderato (.WPS), istanzierà il componente del filtro tramite il suo nome di servizio trovato in queste informazioni e lo utilizzerà per caricare il file. Ogni filtro creato internamente ha la sua propria configurazione di dati e i filtri di documenti nelle estensioni forniscono le loro configurazioni che estendono i dati preinstallati. Così il gestore delle configurazioni deve essere capace di localizzarli e integrare il loro contenuto in una modalità conveniente.

Supporto delle estensione nel gestore di configurazione

Il gestore di configurazione ha un'abilità similare a quella del gestore dei servizi di UNO: può ricercare informazioni in un insieme di directory. La lista delle directory può essere espansa (mediante il configmanager.ini), in questo modo il gestore di configurazione può avere dei "livelli" addizionali. Ha anche l'abilità di utilizzare altre metodologie per aumentare il numero di "livelli", ma questo non viene trattato qui.

Le informazioni di configurazione sono sistemate in una struttura ad albero, i dati possono essere disposti in questa struttura ad ogni livello. Il gestore di configurazione esamina i livelli (directory) in un modo che le informazioni presente nei livelli "alti" rimpiazzano o estendono quelle presenti nei livelli "bassi", in maniera similare a quanto accade nei registri di ms-windows. Le informazioni sono rimpiazzate o estese in base alla tipologia associata alle informazioni; questo è spiegato in schemi di configurazione per i nostri percorsi impostati.

Di default OOo ha due livelli che già conosci: "share" (condiviso tra tutti) e "user" (utente). Il primo è contenuto nelle informazioni preinstallate, mentre il secondo contiene tutte le impostazioni che un utente particolare ha creato per sé stesso. I file di configurazione nelle estensioni di OOo creano due nuovi livelli: "share/uno_packages" e "user/uno_packages". Questi sono tra i livelli di default nel seguente palese ordine: "share" - "share/uno_packages" - "user/uno_packages" - "user".

Così un'estensione può estendere o cambiare la configurazione di OOo fornendo file xcu che sovrascrivono o estendono (uniscono) le impostazioni di configurazione di OOo. Può anche avere la sua propria impostazione di configurazione se provvede file do schema (xcs) per essa.

C'è un altro (abbastanza ovvio) caso d'uso per il concetto di livellamento del gestore di configurazione: sovrascrivere le impostazioni preinstallate di OOo sui livelli di tutti gli utenti. Un amministratore può personalizzare l'installazione di OOo nel suo utente, prendere i file xcu creati che contengono queste personalizzazioni e inserirle in una estensione che installa con il comando "unopkg add --shared" ogni volta che installa, reinstalla o aggiorna OOo. Non c'è bisogno di modificare i file xcu nel "share/registry" manualmente!

Il concetto dei livelli legato al registro dei servizi e alla configurazione sono i principi basilari che creano la potenzialità delle estensioni di OOo.

Impostazione dei percorsi

Alcune informazioni in OpenOffice.org non sono salvate nei file di configurazione xcu, ma in altre locazioni del file system; ad esempio: i template dei documenti (detti anche modelli), autotext, la galleria di immagini, ecc. Certamente anche questi contenuti devono essere installabili mediante l'uso di estensioni, così l'accesso a questi file deve avere un concetto a livelli che permette le estensioni di accedere a questi file. OOo contiene alcuni componenti che gestiscono l'accesso ai file. Noi potevamo estendere questi componenti con le stesse modalità con cui abbiamo esteso la gestione delle configurazioni o il gestore dei servizi (mediante abilitazione all'uso di livelli espliciti), ma abbiamo deciso di riutilizzare le capacità già disponibili del gestore di configurazione.

La locazione dove questi file sono da cercare è definita nella configurazione, nelle impostazioni di percorso. Ogni "percorso" in qualsiasi versione di OOo precedente alla 2.0.4 era o una singola stringa riportante la directory o una lista di stringhe riportante un elenco di directory (percorsi multipli). Sfortunatamente una simile lista non può essere soprascritta nei livelli alti, ma non estesa, così abbiamo bisogno di un nuovo schema di configurazione per i percorsi che utilizzano "insiemi" di stringhe al posto di "liste di stringhe" dato che gli insiemi possono essere ampliati.

Abbiamo iniziato ad utilizzare nuovi schemi per l'impostazione dei percorsi da OpenOffice.org 2.0.4. Abbiamo mantenuto lo schema precedente e i suoi dati per ragioni di compatibilità e abbiamo migrato le definizioni verso i nuovi dati. Il vecchio schema sarà rimosso in OpenOffice.org 3.0.

Nelle versioni recenti di OOo generalmente si possono vedere due o più directory nell'albero o negli alberi di OOo utilizzate per i template: "share" (condivisa tra tutti gli utenti), "user" (personale per ogni utente) e altre condivise. È possibile inoltre che ulteriori percorsi siano stati aggiunti dall'utente o dall'amministratore o dal gestore che ha creato la versione di OOo che state utilizzando.

Dando uno sguardo, in OOo 2.0.4, a: "Opzioni -> OpenOffice.org -> Percorsi", noterete che non tutti i componenti dei percorsi multipli sono visualizzati qui, soltanto le directory per gli elementi "percorsi utente" e "percorsi di scrittura" dal nuovo schema di configurazione. Normalmente in una installazione di default solo una directory è impostata per ogni percorso.

Opzioni -> OpenOffice.org -> Percorsi

Impostazione dei percorsi (OOo 2.0.4 su Debian GNU/Linux e Gnome)

Dall'immagine è possibile vedere i percorsi impostati di default dall'installazione di OOo o modificati dall'utente e/o amministratore del sistema. Quello che non si può vedere qui sono i percorsi impostati dall'installazione di un'estensione, poiché solo chi ha aggiunto tali percorsi deve poterli controllare e quindi poterli rimuovere.

Un miglioramento per gli utenti come per il codice di OOo permette all'utente di selezionare esplicitamente la directory di default dove vuole inserire i propri di dati mediante un radio button. Nella maggior parte dei casi è l'ultimo elemento.

Opzioni -> OpenOffice.org -> Percorsi -> Modifica

Modifica della directory di default (OOo 2.0.4 su Debian GNU/Linux e Gnome)

Estensioni per i template

Un'estensione per i template dei documenti è molto semplice. Principalmente contiene solamente i template organizzati in directory che definiscono le categorie dei template per il gestore dei template dei documenti. In aggiunta deve essere fornito il file Paths.xcu che registra l'estensione nell'insieme delle directory per i template dei documenti. Questo file contiene l'URL della directory dove i template contenuti nell'estensione vengono installati. Se il percorso non è conosciuto quando il template viene creato è sufficiente utilizzare una variabile (%origin%) sostituita in automatico quando il file xcu viene copiato nella locazione finale. La cosa buona è che questa variabile sarà sempre la stessa per ogni estensione di template così non c'è bisogno per l'autore dell'estensione di creare tale directory:

Paths.xcu [xml] <?xml version='1.0' encoding='UTF-8'?>

<oor:component-data oor:package="org.openoffice.Office"

   oor:name="Paths" xmlns:install="http://openoffice.org/2004/installation" 
   xmlns:oor="http://openoffice.org/2001/registry" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<node oor:name="Paths">

<node oor:name="Template" oor:op="fuse"> <node oor:name="InternalPaths"> <node oor:name="%origin%/template" oor:op="fuse"/> </node> </node>

</node> </oor:component-data>

Se si confronta questo codice con quello presente nell'installazione è possibile vedere che entrambi i file contengono qualcosa nei "percorsi interni" che la configurazione unisce nel suo nome di contenitore che rappresenta questo elemento. L'unione è fatta per la parola chiave "fuse" che definisce l'operazione "aggiungimi al contenitore o creane uno nuovo se non esiste".

Esempio

Qui c'è un'"estensione vuota" per template di documenti. Tale estensione vuota è pronta per essere riempita con template.

L'archivio zip ha una directory con nome "templates". Qualsiasi directory creata sotto di essa verrà vista come una categoria di template nel dialogo dei template di OOo. I template possono essere aggiunti in queste sotto-directory. Il titolo del template verrà preso dai metadati del documento (proprietà del documento) o dal nome del file del template se il titolo non è impostato nei metadati. Se una delle tue sotto-directory ha lo stesso nome di una già esistente, allora i tuoi template verranno uniti a quelli già presenti in tale categoria durante la fase di installazione. Provalo, è veramente semplice da fare e da spiegare.


Localizzazione dei template e delle categorie dei template

I titoli delle categorie e dei template possono essere prese dai nomi dei file e delle directory. Questi nomi possono essere localizzati ed utilizzati tutti i caratteri che un archivio zip e il file system di destinazione possono rappresentare. È possibile che i template sono installati su file system che hanno problemi con i nomi per le categorie localizzate (== directory), così il componente del template dei documenti permette di indicare questi nomi localizzati in un file a parte. Il template dei documenti localizzati può essere inserito nei metadati del documento (Proprietà del documento) così non creano problemi qui.

Il nome del file delle localizzazioni è "groupuinames.xml" ed è posizionato nella directory "template" dell'archivio zip. Il suo contenuto è abbastanza semplice. Segue qui sotto un esempio per la localizzazione in italiano di alcune directory che utilizzano dei nomi inglesi:

groupuinames.xml [xml] <?xml version="1.0" encoding="UTF-8"?> <groupuinames:template-group-list xmlns:groupuinames="http://openoffice.org/2006/groupuinames">

       <groupuinames:template-group groupuinames:name="educate" 
               groupuinames:default-ui-name="Istruire" />
       <groupuinames:template-group groupuinames:name="layout" 
               groupuinames:default-ui-name="Impaginazione" />
       <groupuinames:template-group groupuinames:name="misc" 
               groupuinames:default-ui-name="Miscellanea" />
       <groupuinames:template-group groupuinames:name="officorr" 
               groupuinames:default-ui-name="Correzione automatica" />
       <groupuinames:template-group groupuinames:name="offimisc" 
               groupuinames:default-ui-name="Miscellanea" />
       <groupuinames:template-group groupuinames:name="personal" 
               groupuinames:default-ui-name="Documenti privati" />
       <groupuinames:template-group groupuinames:name="presnt" 
               groupuinames:default-ui-name="Presentazioni" />

</groupuinames:template-group-list>

Estensioni per template di più linguaggi

È possibile creare estensioni per template di più linguaggi, basta una piccola modifica alla linea 13 del file Paths.xcu:

Paths.xcu [xml] <?xml version='1.0' encoding='UTF-8'?>

<oor:component-data oor:package="org.openoffice.Office" oor:name="Paths"

   xmlns:install="http://openoffice.org/2004/installation" 
   xmlns:oor="http://openoffice.org/2001/registry" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<node oor:name="Paths">

<node oor:name="Template" oor:op="fuse"> <node oor:name="InternalPaths">

                               <node oor:name="%origin%/template/$(vlang)" oor:op="fuse"/>

</node> </node>

</node>

</oor:component-data>

e directory aggiuntive devono essere create nella directory "templates" usando i codici ISO delle lingue volute (es: "it" per italiano, "de" per tedesco, ...); le lingue devono essere supportate dal language pack di OOo. Ho creato una estensione vuota per i template multilingua che fornisce l'infrastruttura necessaria. Prendila e inserisci i template in tedesco all'interno della directory "de", quelli in inglese in "en-US", quelli in francese in "fr", ecc. La presenza di directory vuoti nell'estensione non è un problema. I file delle localizzazioni (groupuinames.xml) ora però devono essere messi all'interno delle directory specifiche per ogni linguaggio e non direttamente nella directory "template" come si deve fare per un'estensione che supporta un solo linguaggio.

Creando un'estensione di questo tipo si avrà che il solo template installabile sarà quello relativo al linguaggio corrente della GUI. Questo è determinato dalla variabile "$(vlang)" all'interno del percorso. Una soluzione per permettere di cambiare il linguaggio dei template indipendentemente è ancora mancante.

Estensione per il testo automatico

Nota: il testo automatico è attivabile tramite Ctrl-F3 o dal menù: Modifica -> Testo automatico ...

Tutto quello che è stato detto per le estensione dei template si applica anche per le estensioni per il testo automatico. Il file Paths.xcu naturalmente ora non contiene il valore "Template" ma "AutoText". Qui c'è un esempio che può essere riempito con il file per il testo automatico. Attualmente non esiste la funzionalità per esportare un testo automatico e quindi occorre copiare manualmente il file ".bau" (è un file zip) contenente il testo automatico all'interno dell'estensione. Anche la creazione di estensioni con il testo automatico localizzato è uguale a quanto visto con i template: metti i file nelle sottodirectory con i codici ISO delle lingue come puoi vedere nella directory "share/autotext". Come distinzione rispetto ai template qui non è necessario indicare "$(vlang)" per le estensioni multi lingua poiché il componente del gestore del testo automatico implementa internamente l'accesso in dipendenza della lingua.

C'è un problema sulle estensioni per il testo automatico: correntemente la GUI per il testo automatico permette di salvare i testi automatici in qualsiasi directory. Questo è un bug che ha bisogno di essere corretto. Qualsiasi modifica fatta ad un testo automatico all'interno di un'estensione verrà persa quando l'estensione sarà rimossa. Il contenuto delle estensioni non è fatto per essere modificato direttamente!

Estensioni per le gallerie di immagini

Tutto quanto detto circa le estensioni per i template si applica anche per le estensioni per le gallerie di immagini. Il file Paths.xcu naturalmente non contiene il valore "Template", ma contiene il valore "Gallery" che indica la directory in cui devono essere messe le immagini. Qui è disponibile un esempio di template vuote che può essere rimepito con le gallerie tematiche che hai creato. Per ora non è consigliato creare estensioni per le immagini fino a quando questo problema non verrà risolto.

Un altro problema senza soluzione è nella parte riguardante la localizzazione delle gallerie di immagini.

Estensioni per i dizionari e i wordbooks degli utenti

Questa funzionalità non è ancora disponibile poiché bisogna ridisegnare l'accesso ai file per gli strumenti linguistici. Rimani sintonizzato per sapere quando questa parte verrà implementata. Puoi tenere controllata questa segnalazione che riguarda proprio questo argomento.

Personal tools