Qui nessuno si sogna di criticare i port da Linux. Il punto e' che qui stiamo parlando di qualcos'altro. Come ha detto marmotta, e' normale che framework vengano portati su diversi sistemi, ma quante applicazioni per Windows usano Qt? L'1% del totale? In realta' anche meno, tanto che buona parte degli utenti nemmeno ce l'ha installato... Idem per MacOSX e Cocoa. E cosi' dovrebbe essere per AmigaOS, perche' se il trend dovesse essere di 90% di applicazioni con interfaccia Qt, fareste meglio a usare direttamente Linux, che per quelle applicazioni e' casa sua, e non per un discorso di "purezza"... Qt dev'essere un qualcosa in piu', non puo' essere cio' che mi "vende" AmigaOS. Se ne diventa il fulcro significa che il sistema operativo Amiga, in se, e' nient'altro che finito.
Allo stesso modo, inutile citare Odyssey in questo contesto: quello e' un programma al 100% per MorphOS, che usa un motore multipiattaforma. Una cosa decisamente diversa da cio' che stiamo discutendo qui.
Detto cio' ribadisco quel che ho gia' scritto: Qt e' cosa buona se viene usato per progetti di una certa dimensione. E' uno spreco su Amiga per il 90% di cio' che e' stato portato, proprio per le caratteristiche del sistema. Perche' e' uno spreco linkare a 30MB di .so per un programmino da 100kB. Se si tratta di un pacchetto Office, sono il primo a dire che puo' aver senso. Ma al momento, qual'e' l'applicazione Qt che merita tutte quelle risorse? Soprattutto, qual'e' questa killer application?
@samo79:
Grazie per la lista. L'atteggiamento non e' spocchioso, passo solo in rassegna cio' che mi hai indicato...
MuseScore e' interessante per chi suona.
QMetro: programma pensato per tablet e telefonini, per potersi orientare nelle metropolitane anziche' usare le mappe, perche' magari non le hai sotto mano. Vedere la mappa della metropolitana di Londra da casa tua a Perugia o mia a Padova non ha molta utilita'. E nel caso ci sono i siti web per chi ha sistemi desktop e deve fare "route planning" e da casa non ha problemi di costi del roaming internazionale.
Vacuum: Ma un clone Jabber merita tutte quelle risorse? Ce n'era uno MUI per i nostri sistemi, oltretutto.
CutePiano: non e' un port: peggio che peggio! Nello stesso tempo e con lo stesso sforzo si faceva qualcosa di esattamente uguale con GUI ReAction o MUI che non richiedeva 30MB di .so linkati run-time... Questo e' proprio l'esempio di cio' che non dovrebbe accadere. (al di la che una pianola sul desktop ci sia sempre stata sin dai tempi del C64, e sin da quei tempi io la ritenessi inutile..)
ClipGrab: un'interfaccia per MEncoder/ffmpeg... ne esiste una semplice MUI per MorphOS che richiede circa 1MB di RAM per girare e non una trentina...
CobrasIDE: un'IDE. Se perfettamente completa e utilizzabile (cioe' se si gestiscono con successo progetti completi senza impantanarsi ad esempio nella risoluzione dei path Linux), ha un suo motivo. MorphOS ha nel suo CD Scribble, che e' ai livelli di Cubic IDE, ma viene gratis. Ed e' tutto con GUI MUI, pur usando Scintilla.
MeteoStation: se non si ha la stazione meteo USB WS1080 non serve a nulla. Non so perche' lo metti in questa lista. E per scaricare dati che mi dicono che fuori c'e' il sole, non mi pare il caso di usare 30MB di RAM, davvero.
SQLiteMan: questo e' gia' piu' interessante. Non per me, ma in generale e' il meno spreco visto fin'ora.
Hotot: qui arriviamo agli estremi. Questo si linka anche la QtWebKit, solo per partire vuole piu' di 100MB e alla fine hai un client twitter! Che poi sarebbe un'applicazione scritta in JavaScript, la cosa giusta da fare sarebbe vedere di modificarne lo script per farlo girare su OWB o TimberWolf, cosi' come lo hanno creato per girare sotto Chrome... Invece stiamo parlando di un client Twitter che richiede 100MB solo per partire! Con meta' di quella memoria gira OWB, e poi mi gestisco Twitter e tutto quello che vuoi, un client non ha senso se richiede piu' risorse del browser intero... Un client Twitter ha senso se parliamo di quello MUI che si trova su AmiNet (twittAmiga).
QtWeb/Arora: No, davvero, mi servono dei browser abbandonati e/o senza supporto di HTML5? Dovrei forse abbandonare Odyssey per questi cosi qui? Oltretutto abbastanza pachidermici (richiedono un centinaio di Mega l'uno solo per partire...) e mancanti di un sacco di funzionalita'.
Come si vede, noto ben poco che manchi/mancasse nativo. Vedo invece dei grossi sprechi di risorse se si prova a usare diversi di questi programmi contemporaneamente, visto che ognuno si carica le intere Qt all'avvio per conto proprio, e in alcuni casi addirittura l'intero WebKit.
I problemi tecnici non sono risolvibili velocemente: la gestione degli .so e' determinata dal sistema operativo, e non mi pare che rendere shared gli .so sia tra le priorita' degli sviluppatori. E contando anche i tempi che ci impiegano anche feature considerate prioritarie a divenire tangibili..
Comunque che gli .so siano da usare principalmente per port di una certa consistenza sono stati gli stessi Frieden a dirlo nel loro articolo sugli shared object.
@tlosm
Si vede che non conosci la gestione della memoria su Amiga. Innanzitutto, i MB che ti da come liberi su AmigaOS 4 sono solo indicativi, questo e' stato ribadito piu' volte. Allo stesso modo, come ribadito piu' volte nei forum ufficiali di Hyperion, la massima memoria indirizzabile tra fisica e virtuale e' 1.8GB. Questo perche' Amiga e' un sistema a 32bit, gli indirizzi negativi sono codici di errore e nei 2GB rimanenti devono essere mappate tutte le periferiche. Ma se non mi credi, prova ad abilitare la memoria virtuale e copiare in RAM 2GB. Oppure non abilitare la memoria virtuale e dopo il boot copiare in RAM dati per 1870MB che ti dice siano ancora liberi.
Nota: MorphOS usa 256MB di VRAM sulle schede video che li mappano su una sola apertura, che sono la minoranza. Sarebbe interessante invece al contrario provare a mettere piu' di 128MB di dati nella VRAM di una scheda video delle vecchie Radeon che su AmigaOS viene riconosciuta a 256MB e su MorphOS da 128MB, perche' a quel che ne sapevo nemmeno i driver Radeon per AmigaOS 4, al di la di riconoscere la scheda, riuscivano a indirizzare correttamente tutta la memoria se non era contigua. Comunque non ci sono barriere a 128MB di VRAM su MorphOS. L'ho visto io girare su un G5 con scheda X800. 3 anni fa ormai.
No, la ixemul.library non era gli .so del tempo. Era una libreria veramente condivisa (e infatti se si riuscisse a fare una qt.library diverse delle mie osservazioni cadrebbero, solo che tecnicamente e' molto difficile per limitazioni delle librerie che richiederebbero ben piu' lavoro di port).
@Kyle:
E' evidente che ci sono molti meno feedback, domande su IRC e thread su MorphZone, e evidentemente anche mail private, che riguardino le Sam piuttosto che i Mac. Davvero, la differenza di interesse si vede a occhio.
@NubeCheCorre:
OpenGL e' uno standard, TinyGL e' un'implementazione. E' un esempio completamente fuori luogo.
Non si sono reimplementate le Qt qui, sono state portate di peso. Il che, ripeto, va bene per poi usarle per progetti grossi, visto che l'intera libreria deve essere linkata run-time a ogni eseguibile che ne fa uso.
Non e' una questione di ottimizzazione: la memoria usata non diminuira' se non cambiera' la gestione degli shared object su AmigaOS, ma non mi pare questa una priorita', e, detto tra noi, lo sviluppo dell'OS in se sembra ormai praticamente quasi fermo da alcuni anni.
@andres
Esempio interessante VLC su Windows. Li le Qt sono distribuite come plugin a parte (ma analogamente potrebbero essere anche linkate staticamente, non cambierebbe nulla, ma e' per far l'esempio di qualcosa di fattibilissimo su AmigaOS) e infatti la parte di Qt che serve per VLC e che e' contenuta nell'archivio pesa meno di 11MB. Tipico esempio di come, perfino su Windows, adottino strategie per ridurre di circa 3 volte la memoria richiesta. E stiamo parlando di Windows vs. un sistema operativo che si vantava di essere efficiente.
Ecco, una distribuzione ragionevole di VLC su Amiga, secondo me, sarebbe un eseguibile con le parti che servono linkate staticamente. Non avrei molto da dire, a parte che continuerei a preferire il mio MPlayer con GUI MUI che, per quanto poco, mi farebbe risparmiare 7-8MB di RAM e una decina di spazio su disco per far le stesse cose.
Saluti,
Andrea
, rispetto al resto di AmigaOS?
) 
). Vlc ce l'ho su osx, ma solo per sfizio e per quelle rarissime volte che devo aprire un video non compatibile con quicktime (ed è molto raro che succede). Ho anche altre applicazioni qt e se per quello anche in "emulazione" windows con uno pseudo wine integrato (mi viene in mente mp3tag o vecchi giochi per pc). Ma questo solo perchè sono un utente a cui piace "smanettare" e ho anche molte macchine virtuali tra cui Aros 
al massimo quelli piu "avanzati" ci aggiungono qualche codec mancante.
