martedì 9 giugno 2009

BasicAddonBuilder: problemi con OOo3.1 su Mac OS X

Dopo tanto tempo eccomi di nuovo qui.
Pare che BasicAddonBuilder abbia un problema con OpenOffice.org 3.1 su Mac OS X 10.5.7 (Intel)
Un utente tedesco mi segnala infatti che da quando ha aggiornato OpenOffice.org all'ultima versione 3.1, non riesce più ad utilizzare BasicAddonBuilder, ottenendo strani errori.

L'extension peraltro aveva sempre funzionato bene fino alla penultima 3.0
L'errore avviene in corrispondenza di questo codice:
Modulo: DlgWizard_main
-----------------------

Sub Dialog_Initialize
Dim oBasicProvider As Object
Dim oBasicLibrary As Object
Dim mNameList()
Dim sPkgDesc As String

'setup the objects in the dialog
'general controls (step 0)
'setup the Roadmap control
'(the "navigation panel" on the left of the dialog)
InitializeRoadmap

'step 01 controls
With g_oDlgWizardModel
.lstBasicLibraryContainers.StringItemList = GetProviderUINames()
.lstBasicLibraryContainers.SelectedItems = (Array(0))

oBasicProvider = g_mBasicProviders(0).Provider
L'ultima linea è quella che solleva l'errore.
Ecco uno screenshot che mostra il messaggio di errore:
Beh, ora il difficile è scoprire il motivo. Purtroppo non ho a disposizione un Mac per fare delle prove, perciò si accettano idee :-)
Alla prossima.

martedì 17 marzo 2009

Il PLIO rinnova il Consiglio Direttivo

Pochi giorni fa, il 14/03/2009, Il Progetto Linguistico Italiano OpenOffice.org (PLIO) ha rinnovato il proprio esecutivo.
Il nuovo presidente è Italo Vignoli, a cui vanno i miei auguri di buon lavoro.
Io sarò il vice-presidente e ... beh, cercherò di fare del mio meglio!
Gli altri membri del Consiglio Direttivo sono:
Francesca Beatrice Cice
Roberto Galoppini
Flavia Marzano
Andrea Pescetti
Paolo Pozzan
Un ringraziamento particolare e va al presidente uscente, Davide Dozza che negli ultimi anni, con il suo lavoro instancabile ha contribuito al successo di OpenOffice.org in Italia.

venerdì 6 marzo 2009

Tutti a Orvieto per la Conferenza 2009 di OpenOffice.org

Riporto il comunicato del PLIO (Progetto Linguistico Italiano OpenOffice.org):


Trieste, 4 marzo 2009 - PLIO e OrvietoLUG annunciano che la OpenOffice.org Conference 2009 si terrà a Orvieto nel mese di novembre. La proposta presentata dalle due associazioni insieme ad Assessorato all'Informatizzazione del Comune di Orvieto, Fondazione per il Centro Studi "Città di Orvieto", Consorzio SIR-Umbria e CCOS (Centro di Competenza sull'Open Source della Regione Umbria), ha ottenuto il 48% dei voti, e ha superato quelle di Budapest - che sarà la sede della conferenza nel 2010 - e di altre 5 città. Le proposte sono online all'indirizzo: http://marketing.openoffice.org/ooocon2009/cfl/

"L'assegnazione della conferenza 2009 a Orvieto è una conferma del ruolo assunto dalla comunità italiana all'interno dell'ecosistema di OpenOffice.org", commenta Davide Dozza, Presidente dell'Associazione PLIO. "Un'importanza che non sta solo nei numeri che continuano a crescere - i download della versione italiana, che a febbraio sono stati quasi 800.000, e il traffico verso il sito internazionale, che è superiore a 25.000 accessi al giorno - ma anche nella partecipazione dei singoli: Giuseppe Castagno e Paolo Mantovani nell'area dello sviluppo, e Italo Vignoli in quella del marketing. La comunità italiana, inoltre, è tra le poche a svolgere tutte le attività di localizzazione e quality assurance al proprio interno, grazie al lavoro dei volontari".

Le date definitive e il programma della conferenza verranno annunciati nel corso delle prossime settimane. Per la prima volta nella storia della conferenza, ci sarà una sessione parallela nella lingua locale - l'italiano - durante tutta la durata dell'evento. Nella tradizione della comunità, sarà possibile seguire le discussioni sulla mailing list della conferenza, a cui è possibile aderire inviando un email a ooocon2009_discuss-subscribe@marketing.openoffice.org.

Link Utili

Associazione PLIO: http://www.plio.it

OpenOffice.org 3.0 in italiano: http://it.openoffice.org/download/

Guida a OOo 3.0 in inglese (PDF): http://tinyurl.com/GuideOOo30

Modelli in Italiano: http://wiki.services.openoffice.org/wiki/IT/Modelli

FAQ su OOo dal Newsgroup Italiano: http://tinyurl.com/OOoITFAQ

OpenOffice.org nelle altre lingue: http://download.openoffice.org

Estensioni per OOo: http://extensions.services.openoffice.org

L’Associazione PLIO, Progetto Linguistico Italiano OOo, raggruppa la comunità italiana dei volontari che sviluppano, supportano e promuovono la principale suite libera e open source per la produttività negli uffici: OpenOffice.org. Il software usa il formato dei file Open Document Format (standard ISO/IEC 26300), legge e scrive i più diffusi tra i formati proprietari, ed è disponibile per i principali sistemi operativi in circa 100 lingue e dialetti, tanto da poter essere usato nella propria lingua madre da più del 90% della popolazione mondiale. OpenOffice.org viene fornito con la licenza GNU LGPL (Lesser General Public Licence) e può essere utilizzato gratuitamente per ogni scopo, sia privato che commerciale.

PLIO, Progetto Linguistico Italiano OpenOffice.org: http://www.plio.it. Vola e fai volare con i gabbiani di OpenOffice.org: usalo, copialo e regalalo, è legale!



domenica 22 febbraio 2009

OpenOffice.org API: Evoluzione o Stabilità?

In questi mesi, nel pentolone del progetto API ribollono parecchie novità, come l'adozione dell'ereditarietà multipla e un nuovo modello di constructor per i servizi UNO.

Le novità comportano sempre dei cambiamenti, perciò l'eterna discussione sulla dicotomia (vera o presunta) tra evoluzione e stabilità si è riaccesa in modo vivace, alimentata anche dal contributo autorevole di sviluppatori indipendenti come Ariel Constenla-Haile.

La stabilità in questo contesto non va però intesa come l'attitudine di un programma a non andare in crash ogni qualvolta che un raggio cosmico dovesse passare nelle vicinanze.

La trave portante dell'API infatti, non è tanto l'implementazione quanto l'insieme delle specifiche che definiscono e regolano l'interazione tra un programma client e il programma host (OpenOffice.org)

Background

In termini molto generali, si può immaginare l'API come una sorta di vocabolario predefinito, con tanto di convenzioni grammaticali e lessicali, che il programma client deve utilizzare per poter controllare OpenOffice.org.

Il programma client è generalmente sviluppato da terze parti, siano esse semplici utenti che utilizzano le macro o sviluppatori professionisti che integrano OpenOffice.org nelle loro soluzioni software.

Per questo motivo è molto importante che, una volta che gli sviluppatori API abbiano stabilito il “vocabolario” e la “ grammatica” per comunicare non ci siano stravolgimenti ad ogni nuova versione di OpenOffice.org.

Pros&Cons

La politica del progetto API, fortemente difesa da Jürgen Schmidt attuale leader del progetto, è sempre stata coerente, anzi direi granitica su un punto: ciò che è pubblicato non deve essere modificato.

In altre parole, la definizione di un sevizio o di un interfaccia vengono considerati come un contratto vero e proprio tra lo sviluppatore API e i suoi utenti ovvero gli sviluppatori esterni che utilizzano i servizi e le interfacce.

Agli inizi del progetto questa fermezza di propositi venne giudicata indispensabile per creare un clima di fiducia negli sviluppatori esterni, che guardavano con interesse e valutavano se valeva la pena di investire risorse nell'adozione di questa nuova piattaforma.

Tale politica ha indubbiamente pagato. La comunità degli sviluppatori esterni in questi anni è cresciuta enormemente non solo quantitativamente ma anche qualitativamente, raggiungendo livelli di competenza molto elevati.

Per contro, ci sono stati anche dei costi in termini di difficoltà evolutive, basti pensare al difficilissimo parto del componente Base, introdotto con la versione 2.0

Bisogna ricordare che OpenOffice.org era dotato un componente database fin dalla prima versione. Tale componente non aveva una propria interfaccia grafica separata. In pratica il componente base, in background, forniva a tutti gli altri componenti la capacità di interagire con i database.

Nel passaggio alla versione 2.0 questo approccio “pervasivo” venne trasformato in quello basato su documenti che vediamo attualmente.

Questa trasformazione richiese complessi adattamenti se non addirittura veri e propri contorsionismi a livello di API proprio perché la scelta fu quella di mantenere il più possibile la compatibilità con il codice di terze parti preesistente.

Il ciclo di sviluppo API

In altri casi il “costo” per mantenere la compatibilità con il codice preesistente si manifesta in modi più subdoli.

Il ciclo di sviluppo dell'API prevede che un servizi o un interfaccia di nuova creazione siano immediatamente resi pubblici, ma etichettati inizialmente come unpublished.

Questo significa che possono essere utilizzati ma che potrebbero essere soggetti a modifiche e correzioni incompatibili con il codice preesistente.

Trascorso un certo periodo e dopo aver ottenuto qualche feedback da parte dell'utenza il servizio o l'interfaccia vengono ri-etichettati come published e da questo momento non potranno più subire modifiche.

Questo meccanismo ha fatto si che gli sviluppatori tendessero a non documentare pubblicamente i nuovi servizi e comunque, una volta documentati venivano marcati come unpublished per un tempo lunghissimo proprio per non vedersi congelare il proprio lavoro e per tenere sempre aperta la possibilità di correzioni.

Di fatto, questo atteggiamento riluttante rischiava, e rischia tuttora, di vanificare il contratto con gli utilizzatori.

(se ogni nuova interfaccia rimane unpublished a tempo indeterminato la stabilità non sarà mai garantita)

Per questo motivo i mantainer del progetto API hanno comunque obbiettato in più casi che, se un servizio o un'interfaccia sono rimasti disponibili per lungo tempo verranno comunque considerati non modificabili, indipendentemente dallo stato di pubblicazione.

Questo è in palese contraddizione con le regole di pubblicazione volute dagli stessi mantainer, ma, l'orientamento generale è chiaro, si tende a preservare (e con giustissima ragione, aggiungo io) la compatibilità e il contratto con l'utenza ad ogni costo.

domenica 14 dicembre 2008

Macro e Rock&Roll (3)

Dopo avere esaminato e tradotto in StarBasic il modulo FileExtractor, proseguiamo il discorso prendendo velocemente in esame i moduli di codice rimanenti:
  • ThisWorkbook

  • Sheet1

  • LoadModule

  • Module

Modulo ThisWorkbook

Questo modulo contiene le routine collegate agli eventi del documento.

In particolare nella routine Workbook_Open() vengono effettuate alcune inizializzazioni, come ad esempio l'estrazione del file audio, in corrispondenza dell'apertura del documento.

Modulo Sheet1

Qui ci sono le routine collegate agli eventi della tabella "Sheet1". In particolare vengono gestiti i due pulsanti presenti nella tabella.

Modulo LoadModule

Questo modulo contiene solamente la routine LoadVideo()
Questa procedura non viene usata in nessun modo ma è stata inizialmente impiegata dagli sviluppatori per caricare i "fotogrammi" del video in ASCII Art entro alcune celle del foglio elettronico, a partire da un file di testo chiamato 12fps-45sec-cut.txt ottenuto presumibilmente processando il "vero" file video degli AC/DC.
Osservando il codice possiamo capire che le celle della colona Q a partire dalla riga 100 contengono ciascuna un fotogramma ASCII Art. La cella Q99 invece contiene il logo del gruppo, che viene mostrato all'apertura del documento.

Modulo Module.

Questo è il modulo di codice che contiene le routine che eseguono materialmente il video musicale. Possiamo vedere che il file wav viene eseguito sfruttando alcune chiamate all'API di Windows dichiarate all'inizio del codice:

Private Declare Function sndPlaySound Lib "winmm.dll" Alias "sndPlaySoundA" _ 
(
ByVal lpszSoundName As String, ByVal uFlags As Long) As Long

L'istruzione Declare funziona anche in StarBasic, però questo approccio funzionerebbe solamente in Windows, per cui nella versione OpenOffice.org verrà senz'altro preferito l'approccio mostrato in questo post
La routine PlayVideo() è responsabile della proiezione del video nella cella B2 (in realtà si tratta di una cella risultante dall'unione dell'intervallo B2:L20)
Il codice è assolutamente semplice (ho rimosso le parti non essenziali):


VBA:
i =100
Do
While Sheet1.Cells(i, 17).Value <> ""
'[...]
Sheet1.Range("B2").Value = Sheet1.Cells(i, 17).Value
'[...]
i = i + 1
Loop

In pratica si tratta di un ciclo che copia il contenuto delle celle della colonna Q:Q a partire da Q100 nella cella di destinazione B2.
Il risultato è la proiezione del video in ASCII Art.
Dato che si tratta di un video a 12fps occorre introdurre un ritardo di 1/12 sec tra un fotogramma e l'altro.
Gli sviluppatori del codice VBA originale hanno utilizzato la funzione di libreria Timer ma in StarBasic è disponibile la più comoda funzione Wait.
Traducendo:

StarBasic:
i = 99
oSh = ThisComponent.Sheets(0)
Do While oSh.getCellByPosition(16, i).String <> ""
oSh.getCellRangeByName("B2").String = oSh.getCellByPosition(16, i).String
Wait 83 '1/12 sec
i = i + 1
Loop

Ed ecco finalmente il nostro video su OpenOffice.org Calc!!
Ora manca solo l'audio ma, ricordando quanto riportato qui, non ci vuole molto a mettere insieme le cose:

REM  *****  BASIC  *****
Sub Main
sMMUrl = "file:///home/paolo/Scrivania/acdc/MMFiles/acdc.wav"
oMediaMgr = CreateUnoService("com.sun.star.media.Manager_Java")
oMMPlayer = oMediaMgr.createPlayer(sMMUrl)
oMMPlayer.start
i = 99
oSh = ThisComponent.Sheets(0)
Do
While oSh.getCellByPosition(16, i).String <> ""
oSh.getCellRangeByName("B2").String = oSh.getCellByPosition(16, i).String
Wait 83 '1/12 sec i = i + 1
Loop

oMMPlayer.stop
End Sub

Questo il risultato finale:

martedì 4 novembre 2008

Macro e Rock&Roll (2)

Come preannunciato nel post precedente, tenterò di fare qualche osservazione più approfondita sul primo video musicale su Excel. Se non fosse già chiaro, lo scopo finale di tutte queste elucubrazioni è quello di "tradurre" il codice originale VBA in StarBasic, in modo da ottenere il primo video musicale per OpenOffice.org :-)
Il file originale contiene alcuni moduli macro scritti ovviamente in VBA (Visual Basic for Applications):
  • FileExtractor
  • LoadModule
  • Module
  • Sheet1
  • ThisWorkbook
Quando il documento Excel viene aperto da OpenOffice.org Calc, il codice contenuto in tali moduli viene importato in forma commentata, ovvero il filtro di importazione antepone un'istruzione Rem a tutte le linee di codice. Inoltre, tutto il codice di ciascun modulo viene racchiuso in una routine che prende il nome del modulo stesso.
Con un cerca & sostituisci si possono eliminare velocemente tutte le istruzioni Rem, mentre le routine aggiunte dal filtro di importazione dovranno essere eliminate manualmente.
Dopo queste operazioni di pulizia, il codice non sarà comunque compatibile con Calc ma potremo osservarlo più comodamente.

Modulo FileExtractor
Questo modulo contiene una sola routine: ExtractWAV.
L'osservazione del codice ci rivela che il nostro documento Excel "nasconde" un file audio in formato wav. In effetti il file wav è stato accodato al file Excel.
Evidentemente gli sviluppatori non hanno trovato un metodo meno rozzo per nascondere un file alieno all'interno di un documento Excel.
Va sottolineato che OpenOffice.org permette di includere contenuti alieni nei documenti usando un approccio ben più raffinato (che magari vedremo in futuro)
Esaminando i contenuti del documento Excel, si nota anche un oggetto OLE di circa 1.9Mb che si rivela essere una copia dello stesso file wav accodato. Si tratta forse del residuo di qualche esperimento che non ha dato il risultato voluto e porta a raddoppiare inutilmente la dimensione del file da scaricare.
La routine ExtractFile viene chiamata durante l'apertura del documento e si occupa appunto di estrarre il file wav dalla coda del documento Excel. Il codice è abbastanza semplice e per lavorare con il file-system non usa oggetti API ma le semplici funzioni runtime offerte da VBA e che sono presenti anche i StarBasic.
Di fatto, la routine sarebbe quasi completamente compatibile con StarBasic a parte alcune semplici chiamate API
Vediamo dunque come "tradurre" il resto del codice in modo da estrarre il file wav.
La routine si può scomporre in tre blocchi:
Nel primo blocco il documento Excel con accodato il file wav viene interamente caricato in memoria sotto forma di array di bytes:
VBA:
tmpFileName = ThisWorkbook.Path & _
Application.PathSeparator & ThisWorkbook.Name
myFileId = FreeFile
Open tmpFileName For Binary As #myFileId
MyFileLen = LOF(myFileId)
ReDim myArr(MyFileLen - 1)
Get myFileId, , myArr()
Close myFileId

La prima linea di codice recupera il percorso del documento e la traduzione in StarBasic risulta particolarmente compatta:
tmpFileName = ThisComponent.URL
Per il resto si tratta di istruzioni che esistono anche in Starbasic, quindi il codice dovrebbe essere direttamente eseguibile.
Purtroppo, la versione Starbasic di Get funziona solo con le stringhe e non con gli arrays nonostante la documentazione sostenga il contrario. Si tratta indubbiamente di un bug, che segnalerò quanto prima.
Poco male perchè mediante l'API di OpenOffice.org è possibile utilizzare un approccio decisamente più elegante e potente:
StarBasic:
oUcb = CreateUnoService("com.sun.star.ucb.SimpleFileAccess")
oFileStream = oUcb.openFileRead(ThisComponent.URL)
iFileLen = oFileStream.Length
Dim myArr() As Byte
iResult = oFileStream.readBytes(myArr(), iFileLen)
Ora che abbiamo ottenuto un array contenente l'intero documento, occorre analizzarlo per estrarre la parte finale contenente il file wav. Questo viene effettuato nel secondo blocco di codice:
VBA:
Application.ScreenUpdating = False
i = 0
Do While i < MyFileLen
If myArr(i) = &H52 Then 'Looking for RIFF
If myArr(i + 1) = &H49 And _
myArr(i + 2) = &H46 And _
myArr(i + 3) = &H46 Then
FileLen = CLng(&H1000000) * myArr(i + 7) + _
CLng(&H10000) * myArr(i + 6) + _
CLng(&H100) * myArr(i + 5) + _
myArr(i + 4)
FileLen = FileLen + 8
ReDim fileArray(FileLen - 1)
For myIndex = 0 To FileLen - 1
fileArray(myIndex) = myArr(i + myIndex)
Next myIndex
Exit Do
Else
i = i + 4
End If
Else
i = i + 1
End If
Loop
La prima istruzione del blocco dovrebbe servire per inibire il refresh della finestra durante le elaborazioni successive, migliorando le prestazioni, ma pare che gli sviluppatori abbiano scordato di ripristinare lo stato della proprietà a True una volta terminate le elaborazioni.
L'equivalente StarBasic di questa tecnica è il seguente:
StarBasic:
ThisComponent.lockControllers
...(codice da eseguire)
ThisComponent.unlockControllers
Nel nostro caso il documento finale userà una tecnica differente per includere il file wav e useremo la routine che stiamo traducendo solo una volta, perciò possiamo tranquillamente omettere queste tecniche per migliorare le performances.
Tutte le rimanenti istruzioni del secondo blocco possono essere eseguite direttamente in StarBasic, senza nessuna modifica.
Come si può vedere, il codice effettua una scansione dell'array precedentemente creato alla ricerca della stringa "AIFF" che segna l'inizio del file wav da estrarre.
Tutti i bytes a partire da questa stringa vengono posti in un secondo array chiamato fileArray() che, una volta terminato il ciclo conterrà il file wav sotto forma di sequenza di bytes.
Il terzo ed ultimo blocco prende l'array creato nel blocco precedente e lo salva in un file:
VBA:
myFileId = FreeFile

tmpFileName = _
Left(tmpFileName, Len(tmpFileName) - 4) & ".wav"
Open tmpFileName For Binary As #myFileId
Put #myFileId, , fileArray
Close myFileId
Per il problema citato precedentemente con l'istruzione Get non possiamo usare queste linee di codice così come sono ma dovremo usare l'approccio basato sull'API di OpenOffice.org:
StarBasic:
sOutUrl = Left(ThisComponent.URL, Len(ThisComponent.URL) - 4) & ".wav"
oFileStream = oUcb.openFileWrite(sOutUrl)
oFileStream.writeBytes(fileArray())
oFileStream.flush
oFileStream.closeOutput
Bene! siamo giunti al termine di questo faticoso lavoro. Detto per inciso, la routine ottenuta, sebbene funzionante è ben lungi dall'essere ottimizzata, anzi, il codice VBA di partenza è particolarmente sprecone sia in termini di RAM che di processore, ma, dato che non siamo interessati ad usare le stesse tecniche nel nostro documento Calc, non vale la pena di correggere l'impostazione data dagli sviluppatori originali.
Mettendo assieme i pezzi e lanciando la routine otterremo (dopo paziente attesa) il file acdc.wav perfettamente funzionante e contenente circa 45 secondi di puro metallo pesante :-)
Mettiamolo da parte perchè nei prossimi post vedremo come utilizzarlo nella versione finale del primo video musicale per OpenOffice.org
A presto!

lunedì 3 novembre 2008

Macro e Rock&Roll

Girovagando per la rete ho scoperto Il primo video musicale su Excel!
Si tratta di un brano dei mitici AC/DC.
Chi non ha Excel (come il sottoscritto) può gustarsi il foglio elettronico in azione in questo filmato su Youtube
Si tratta di un video in ASCII Art che viene proiettato in uno spazio rettangolare ottenuto mediante l'unione di alcune celle del foglio elettronico.
Ovviamente non esiste una versione per OpenOffice.org ma non potevo accontentarmi di vedere questo giocattolo solo attraverso Youtube, perciò me lo sono scaricato e ho provato ad aprirlo con Calc (su Ubuntu 8.04)
Il file scaricato (acdc.xls) "pesa" circa 3.8 MB. Calc è in grado di aprilo senza difficoltà.
Questo è il risultato:


Come si può vedere il la schermata iniziale non è visualizzata correttamente, probabilmente perchè il font previsto non è presente nel mio sistema.
E' sufficiente impostare il font della cella B2 (lo "schermo di proiezione" del video musicale) con un qualsiasi font a larghezza fissa (ad esempio Courier New) per correggere il problema:


Come si vede anche nelle immagini, il documento presenta un paio di pulsanti che servono per eseguire e per fermare il video musicale.
Questi pulsanti sono collegati all'esecuzione di alcune macro, che vedremo in dettaglio nei prossimi post.
A presto!