Programmare con AmigaOS 3.5 di Bernardo Innocenti Abstract Se l'OS 3.5 costituisce un upgrade appetibile per qualsiasi utente Amiga, lo e' ancor di piu' per uno sviluppatore. Difatti in questa nuova versione cio' che "non si vede" vale ben piu' di cio' che si vede: oltre ad apportare innumerevoli migliorie a quasi tutti i componenti del Workbench, la squadra dell'OS 3.5 si e' preoccupata anche di aggiungere un vasto assortimento di nuove funzionalita' a supporto delle applicazioni. Introduzione Sul CD allegato a questo numero della rivista troverete le note ufficiali per gli sviluppatori che riassumono le nuove caratteristiche dell'OS 3.5. Tra gli argomenti trattati, troverete delle informazioni sulla compatibilita' con applicazioni e librerie di terze parti nonche' alcuni utili consigli per aggiornare le vostre applicazioni. Si tratta di un'anteprima esclusiva per AmigaLife della documentazione che fara' parte dell'Amiga Developer CD, di prossima uscita. Per ovvie ragioni di spazio, non ci e' possibile pubblicare sulla rivista l'intero testo tradotto in italiano. In questo numero ci limiteremo ad una rapida panoramica sulle novita' di rilievo, mentre, a partire dal prossimo numero, AmigaLife pubblichera' una serie di articoli per approfondire ciascun argomento. Workbench Olaf Barthel e' senza dubbio uno tra i piu' produttivi sviluppatori che la comunita' Amiga abbia mai avuto. Nel caso di AmigaOS 3.5, si puo' tranquillamente affermare che da solo egli ha rappresentato meta' della forza lavoro a disposizione del progetto. Tra i lavori eseguiti da Olaf, il Workbench e' senza dubbio quello che ha richiesto l'impegno maggiore. Basti pensare che il documento che elenca i cambiamenti apportati a partire dalla workbench.library V40 occupa ben XX kilobytes. Per cominciare, il nuovo Workbench utilizza il formato di icone a colori gestito della icon.library V44, della quale ci occuperemo piu' avanti, oltre a garantire la compatibilita' con le "vecchie" icone NewIcon (solo se e' presente la newicon.library). L'altra grande novita' e' la presenza di una potente porta ARexx dotata di oltre XX comandi, per la felicita' degli sviluppatori e degli utenti piu' smaliziati. E' stata inoltre migliorata l'API in modo da permettere una maggiore interazione con le applicazioni e le commodities. Tre nuove funzioni presenti nella workbench.library permettono rispettivamente di aprire, chiudere e rendere visibili le finestre del Workbench. Non solo: e' finalmente possibile far lanciare al Workbench dei programmi come se si clickasse due volte sulla loro icona, senza dover ricorrere a librerie externe come la wbstart.library o il WBStart-Handler che "simulano" la partenza da Workbench in modo piu' o meno compatibile. Grazie a WorkbenchControl(), e' ora possibile scrivere delle commodity "pulite" che permettono di configurare o estendere il Workbench senza bisogno di "patchare" mezzo sistema operativo. Le Drop Zones sono un'utile estensione al meccanismo di drag & drop delle icone che permette di specificare per ogni AppWindow una o piu' aree sensibili al rilascio delle icone. Questa caratteristica permette sia alle applicazioni che al Worbench di reagire con un "feedback" visivo nel momento in cui un'icona viene spostata su una Drop Zone. Inoltre, sfruttata opportunamente, questa caratteristica consente di realizzare delle "toolbar", dei menu o delle listview in cui si possono inserire icone usando il drag & drop. Un'altra gradita novita' riguarda invece le AppIcon, che possono ora reagire ai comandi presenti nel menu del Workbench (Copia, Rinomina, Informazioni, etc.) come le normali icone. Il programma che ha creato l'icona riceve un nuovo tipo di AppMessage dal Workbench per il quale deve eseguire un'azione appropriata per la AppIcon in questione. Icon Library La novita' piu' appariscente nella icon.library e' il nuovo sistema di icone a colori (palette mapped icons). Per mantenere la compatibilita' verso il basso, il formato dei file .info e' stato esteso in modo da contenere sia le immagini vecchio stile, sia quelle di nuovo tipo. Due nuove funzioni, GetIconTagList() e PutIconTagList() consentono di caricare e salvare icone palette mapped. Entrambe prevedono il passaggio dei parametri tramite taglist per una maggiore flessibilita' ed estendibilita'. Le vecchie funzioni GetDiskObject() e GetDiskObjectNew() sono state mantenute e ritornano icone in formato compatibile, prive cioe' delle nuove immagini. Le nuove icone vengono rimappate automaticamente alla palette dello schermo in cui devono essere visualizzate (non necessariamente il Workbench). Questa funzione viene svolta automaticamente da GetIconTagList(), ma puo' essere controllata manualmente usando la nuova funzione LayoutIcon(). Le applicazioni che mostrano icone nella propria GUI possono ora avvalersi della funzione DrawIconState() anziche' ricorrere a delle routine "fatte in casa". Se in futuro il formato delle icone dovesse essere esteso ulteriormente, l'uso di DrawIconState() permettera' alle applicazioni di disegnare le icone in modo sempre corretto. La funzione IconControlA() permette di cambiare numerose impostazioni che riguardano le icone. E' pensata sopratutto per le commodities che permettono di modificare il look delle icone o di associare delle icone di default ai file che ne sono sprovvisti. Si potrebbe pensare che il nuovo sistema di icone dell'OS 3.6 altro non sia che un'imitazione, peraltro non compatibile, dello standard de-facto creato da NewIcons. Tuttavia, la scelta di adottare un sistema differente e' giustificata dalla volonta' di integrare nel sistema le icone palette mapped sia per quanto riguarda il formato (le NewIcons memorizzavano le immagini all'interno dei tooltypes), sia dal punto di vista dell'API. Picture datatype Finalmente e' stato integrato nel sistema il supporto per immagini truecolor. Il picture.datatype V40 distribuito con l'OS 3.1 aveva numerose deficienze che lo rendevano inadeguato ai sistemi RTG che vennero sviluppati pressappoco nello stesso periodo. Per questo motivo non ci e' voluto molto perche' apparissero delle versioni sostitutive fornite da CyberGraphX e Picasso 96. Riproporre un picture.datatype obsoleto nell'OS 3.5 non avrebbe avuto senso e percio' Olaf Barthel ha riveduto e corretto la versione originariamente distribuita con il Picasso 96 rendendola indipendente dal sistema RTG utilizzato, migliorandone le prestazioni e aggiungendo alcune nuove caratteristiche. Il nuovo picture.datatype e' in grado di convertire bitmap da qualsiasi formato al formato dello schermo su cui si vuole visualizzare il datatype. Sono supportati perfino l'HAM e l'EHB. E' inoltre possibile scegliere tra due algoritmi di dithering e selezionare i singoli fotogrammi contenuti nei formati che permettono di memorizzare immagini multiple (come il GIF animato). Installer Anche il buon vecchio Installer e' stato portato al passo coi tempi. La prima cosa che salta agli occhi quando si installa per la prima volta l'OS 3.5 e' che l'Installer si apre su uno schermo a parte, con un gradevole effetto di fading sullo sfondo e alcune immagini che accompagnano l'installazione. Queste nuove caratteristiche fanno parte delle estensioni "multimediali" presenti nel nuovo Installer. Prima di storcere il naso e dire che queste cose vi ricordano ben altri sistemi operativi, tenete presente che il supporto per immagini e suoni avviene grazie ai datatypes e quindi non appesantisce piu' di tanto l'Installer. Ultima ma non meno importante, la funzione di "backtracing", che finalmente permette all'utente di tornare indietro nel caso abbia commesso un errore. Questa caratteristica richiede un minimo di collaborazione da parte dello script di installazione, ma evita all'utente la frustrazione di dover annullare l'installazione e ricominciare dall'inizio. L'Installer possiede ora dei comandi che permettono di interagire con il Workbench per lanciare applicazioni e aprire, chiudere o rendere visibili i cassetti. SetPatch Il nuovo SetPatch e' frutto del lavoro di Heinz Wrobel, un altro nome di rilievo tra gli sviluppatori Amiga. Egli e' inoltre l'autore del nuovo FastFileSystem e dello scsi.device, che difatti vengono caricati automaticamente da SetPatch. L'altra importante funzione di SetPatch e' di rimuovere le versioni residenti in ROM della icon.library e della workbench.library, in modo che vengano caricate le versioni aggiornate presenti su disco. GUI La novita' piu' importante dal punto di vista degli sviluppatori resta comunque la nuova GUI ReAction, che trae le sue radici dal precedente ClassAct. La mia prima impressione su ReAction e' stata piuttosto negativa: a prima vista sembra trattarsi di un ennesimo toolkit per la GUI senza grandi pretese. Ma un rapido esame degli AutoDocs rivela che il design e' tuttaltro che banale. Le classi sono ben integrate tra loro ed e' piuttosto facile estenderle o crearne di nuove. Il motore di layout e' versatile ed efficiente, e gli oggetti possono interagire tra loro utilizzando i messaggi boopsi. Tra breve sara' disponibile ReActor, un editor di GUI che automatizzera' la parte piu' tediosa e ripetitiva della crezione dell'interfaccia utente. Non si tratta di un generatore di codice, quindi non pone limiti all'impostazione del programma o ai linguaggi supportati. A detta dell'autore Jochen Becher, ReActor sara' un prodotto molto versatile piuttosto che di facile impiego: per usarlo e' necessaria una conoscenza non superficiale delle classi boopsi che si utilizzano. Per questo mese e' tutto. Augurandoci che il Native Developer Kit ed il Developer CD siano rilasciati al piu' presto, attendiamo con impazienza che i programmatori acquistino padronanza con le novita' introdotte nell'AmigaOS 3.5 per sviluppare applicazioni che le sfruttino.