Attendendo ulteriori sviluppi del progetto abbiamo intanto oggi un buon livello di integrazione tra GNUStep e GNOME: con il backend “cairo” di GNUStep possiamo eseguire applicazioni GNUStep in un ambiente desktop GNOME anche se il comportamento di menu e finestre, essendo difforme dal comportamento classico di Gnome, offre non pochi fraintendimenti all’utente inesperto.
I primi passi di iLinux sono stati fatti anche e non solo osservando i progressi del progetto GNUStep (http://www.gnustep.org/).
Abbiamo intravisto in questo progetto, quasi fosse una speranza, un qualcosa che non è nei suoi scopi, ma che probabilmente potrebbe derivarne come ricaduta.
Sappiamo che gli scopi del progetto essenzialmente non sono di “clonare” Cocoa e dunque di mimare completamente il mondo MacOSX; dunque ben lungi da noi il pensiero la semplice adozione delle API GNUStep ci possa portare alla realizzazione di applicazioni cross-platform a livello binario.
Certo è che potrà essere in primo luogo uno strumento completo di omologazione a livello di conoscenze e tecnologie necessarie per lo sviluppo nel mondo MacOSX e in quello Linux, ed in secondo luogo una possibilità di realizzare programmi in entrambi i mondi senza passare per le “forche caudine” di un “porting”, ma eventualmente semplicemente “ricompilando” (mantenendo il profilo dell’applicazione basso, e usando le versioni più vecchie delle API MacOSX).
Certo sarebbe bello possedere uno strumento che crei un bundle unico (fat-bundle) compatibile con entrambi i mondi, in un unica compilazione, tale da vedere un risultato simile:
Dal punto di vista del runtime, immaginiamo compito del comando “open” in MacOSX o “openapp” in GNUStep/Linux (e forse dei relativi framework “AppKit”) quello di ricercare la compatibilità con questo “fat-bundle”: cercare le componenti binarie e le risorse necessarie all’esecuzione dell’applicazione.
Ma questo rimane per ora ancora visione del nostro “sogno”.
Però, ad osservar bene, in realtà in GNUStep qualcosa di simile è pur previsto, e ci chiediamo se non sia così sin dalle origine di NextStep, passando per OpenStep e dunque non sia anche in MacOSX: grazie alla variabile ambientale LIBRARY_COMBO definita in (/usr/GNUstep/System/Library/Makefiles/GNUstep.sh) , il comando “openapp” di GNUStep è capace di gestire i seguenti “formati” di bundle (e opportunamente modificato anche altri):
gnu-gnu-gnu
apple-*
Nel primo caso apre l’eseguibile in un percorso
$openapp_full_appname/$GNUSTEP_HOST_CPU/$GNUSTEP_HOST_OS/$LIBRARY_COMBO/$openapp_appname
che rispecchia la forma dei bundle generati per le applicazioni GNUStep da ProjectCenter.
Nel secondo caso apre l’eseguibile nel percorso canonico degli applicativi MacOSX:
$openapp_full_appname/Contents/MacOS/$openapp_appname
dove $openapp_full_appname è il percorso assoluto del bundle dell’applicazione comprensivo di estensione .app, mentre $openapp_appname è il solo nome dell’applicazione privo di estensione .app.
openapp è dunque in grado di aprire (dato /Users/foo/Applications tra i percorsi di ricerca) un eseguibile in
/Users/foo/Applications/myApp.app/Contents/MacOS/myApp
e dunque teoricamente una comune applicazione MacOSX.
Naturalmente esiste (ma non è il default) una variante “flatten” (schiacciata) dei percorsi di ricerca, per cui si ha una riduzione del percoso non-apple:
$openapp_full_appname/$openapp_appname
Ora è chiaro che i vincoli più grossi saranno nel framework AppKit di GNUStep e segnatamente nel loader dei NIB, che non essendo a tuttora compatibile con quelli MacOSX non sarebbe in grado di eseguire applicativi che non siano sviluppati per GNUStep.
La questione di compatibilità binaria è un poco più sfuggente, ma sembra facile che versioni puramente PowerPC o puramente Intel di applicativi potrebbero essere incapsulate nel bundle, nella specifica cartella Linux, da eseguirsi nella corretta architettura per il sistema.
E’ da escludere a priori in questo discorso l’utilizzo di una tecnologia simile all’Universal-Binary, che probabilmente è una tecnologia proprietaria Apple; ma non è grave, dato che non ci sono nel mondo Linux le necessità di “migrazione” quale hanno sofferto gli utenti Mac.
Nel progetto GNUStep la compatibilità per i NIB del MacOSX è in corso di realizzazione. Non sappiamo se questo coinvolgerà GORM e i suoi “nib” in formato .gorm: per il momento si parla di possibilità di importare i NIB in sede di runtime dell’applicativo o comunque importazione/conversione in GORM.
La possibilità che GNUStep rimpiazzi completamente il formato .gorm con il formato NIB/XIB è difficile da immaginare, allo stato, dato che ciò comporterebbe la perdita di compatibilità verso le vecchie versioni di applicazioni. Avere una compatibilità è comunque tantissimo.
Nel momento in cui la compatibilità sarà pronta è evidente che NIB creati con InterfaceBuilder di MacOSX, magari limitando l’uso di oggetti di AppKit alle sole versioni disponibili in 10.2, saranno facilmente portabili in ambito GNUStep.
Insomma, tenendo a freno ricercate esigenze estetiche e limitando l’adozione delle ultimissime tecnologie Cocoa (vedi CoreData), si potrebbero costruire interfaccia ed implementazione completamente compatibili a livello di compilazione e di runtime con GNUStep, magari solo con il semplice sforzo di ricreare il progetto di sviluppo (non pretendiamo che anche ProjectCenter abbia a dover trovare una compatibilità con XCode3 e futuri).
Sappiamo che oggigiorno molto del lavoro “pesante” è la costruzione dell’interfaccia grafica, e avere un RAD Tool come InterfaceBuilder/GORM completamente compatibili creerà un potente cross-over tra i due mondi, più semplice e più naturale che l’adozione di soluzioni come quelle date dal progetto Renaissance (http://www.gnustep.it/Renaissance/: che passa per la scrittura di uno specifico .xml che descriva in un modo “terzo” rispetto a IB o GORM l’interfaccia grafica).
Attendiamo dunque fiduciosi i progressi del progetto.
Comunque grazie a GNUStep, un piccolo pezzo di MacOSX può vivere e crescere nel nostro Linux.