Mozilla Firefox su AmigaOS !!

[NubeCheCorre]

si infatti, poi se pensiamo che dovrebbe essere "amighizzato" e che amiga os e' piu' leggero di altri os, dovrebbe essere usabile senza problemi..

[Seiya]

Sostanzialmente stanno portando XUL/XULRunner su OS4, sarebbe l'UI su cui è basato Firefox (e tutta la suite di Mozilla, quindi anche thunderbird, ecc...). E' un pò lungo da spiegare, ma XUL si basa su XML/CSS/JS e attraverso le interfacce XPCOM permette d'interagire sulle parti non riguardanti l'UI (file, ecc). In pratica è un ambiente di programmazione...

in un vecchio articolo del 2007 qualcuno snobbava già XUL per l'uscita di XAML (se scritto così) dato che xul rendeva tutto più complicato.

[afxgroup]

INFORMAZIONE DI SERVIZIO:



Andrea chiedo a te che sei esperto di programmazione...

TU come lo vedi questo porting di Firefox sotto Amiga?

E' reale ed usabile o è solo "un esercizio di stile" per dimostrare quanto sono bravi i Frieden, ma poi non servirà a niente perché lento e inusabile?

Insomma hai visto qualcosa all'opera?

Hai solo info generiche?

Sei a conoscenza del progetto nei suoi dettagli?

Ti hanno confessato info riservate, tipo velocità di esecuzione, bug, problemi di realizzazione?

Dicci Andrea, dicci!

Non so una mazza.. so solo che ad OWB sono cambiate milioni di cose e mi tocca cominciare a mandare un po' di patches.. Se uscirà firefox ne sarò felice perchè è il mio browser su tutte le piattaforme che uso (MAC/WIN/LINUX)
Io penso che se hanno fatto un bounty sono già a buon punto altrimenti non l'avrebbero fatto. Secondo me racimolata una certa cifra e quando avranno un buon eseguibile busseranno alla cassa..

P.S.
Ritornando ad OWB ripeto per l'ennesima volta che è una ca**ata avere 4 OS e 4 versioni diverse.. non mi venite a parlare di MUI o REACTION perchè non è quello il problema ma la totale assenza di collaborazione anche per le parti comuni.. la GUI saranno si e no 2 files su OWB..

[NubeCheCorre]

ma allora non e' possibile creare una pagina di support per owb, per tutte le versioni, e fare in modo che i vari programmatori uppino li' i loro sorgenti a disposizione di tutti gli os, cosi' si sviluppa in parallelo per tutti ?..

[samo79]

ma allora non e' possibile creare una pagina di support per owb, per tutte le versioni, e fare in modo che i vari programmatori uppino li' i loro sorgenti a disposizione di tutti gli os, cosi' si sviluppa in parallelo per tutti ?..

Ci sarebbe già, ed è il trunk di Sand-Labs ....

[ShInKurO]

in un vecchio articolo del 2007 qualcuno snobbava già XUL per l'uscita di XAML (se scritto così) dato che xul rendeva tutto più complicato.

Io non ho mica scritto che programmare con XUL sia facilissimo :)
Per esempio è risaputo che le API di BeOS non sono così facili da programmare...l'OS però ha molti adepti per altri motivi...

[ShInKurO]

ma allora non e' possibile creare una pagina di support per owb, per tutte le versioni, e fare in modo che i vari programmatori uppino li' i loro sorgenti a disposizione di tutti gli os, cosi' si sviluppa in parallelo per tutti ?..

Purtroppo è partito tutto male dall'inizio (non da quando Andrea ha fatto il porting, ma da quando è stata aggiunta una GUI abozzata su OS4). Gli amighisti sono inclini alla non collaborazione, per farli collaborare devi mettere tutto "su un piatto d'argento". Se per esempio l'abozzo di GUI fosse stato fatto in MUI, allora Fab avrebbe continuato/migliorato quel tipo di GUI, mantenendo compatibilità con MUI3.9, così su AROS avrebbero fatto ancora meno lavoro.
Ma visto che è stata introdotta una GUI Reaction, Fab si è occupato della GUI per MorphOS solamente, ovviamente usando le caratteristiche di MUI4 (visto che non doveva rimanere compatibile con nulla, perchè usare le API di MUI3.x?). Chi lo ha portato su AROS non ha dunque trovato alcuna compatibilità con cui iniziare il porting e quindi ha dovuto rifare lo stesso lavoro, ma rendendo tutto compatibile con le API di MUI3.x (che però saranno sicuramente "inquinate" da qualche estensione Zune, sempre per il discorso che non c'era alcuna compatibilità da mantenere).

In conclusione, sostanzialmente la psicologia amighista è abbastanza semplice da comprendere: se gli dai un qualcosa con cui dover mantenere la compatibilità e un minimo aiuto, allora la collaborazione avviene, in caso contrario nisbia.

Come cercare di risolvere tutto questo allo stato attuale? Dipende da chi vuole farlo (se lo vuole fare). Partiamo dal presupposto che non avrà alcun aiuto da nessuna delle parti, il tizio in questione dovrebbe prendere il port di Fab e sostituire le classi MUI4 utilizzate con classi MUI3.x che dovrebbe scrivere da zero. In questo modo sicuramente il suo porting verrebbe preso in considerazione anche da AROS (perchè la UI di OWB MOS è più avanzata di quella AROS).
Se invece non si è in grado di fare una cosa del genere allora si potrebbe prendere la GUI di OWB AROS e portarla su OS4, ma ovviamente la controparte MOS non avrebbe alcun interesse nella collaborazione, in quanto la loro versione risulterebbe comunque più avanzata.
Da notare che più si lascia tutto al volere dei singoli porting, più tutto risulterà complicato.

Non sono cose trascendentali, solo che ci vuole tempo e una buona conoscenza MUI (4, che non hanno proprio tutti, e le API MUI4 non sono documentatissime. Se fossi più esperto potrei farlo anch'io, visto che non mi costerebbe nulla stare in chat con Fab a rompergli la testa :DD, il punto è che non ho proprio tempo. Come ho già detto io ho avuto un'ottima esperienza con il MorphOS team, sono sempre stati disponibili a delucidazioni, e non solo sulla programmazione MUI, ma anche su quella Amiga, e addirittura su quella OS4, soprattutto itix è veramente disponibile. Basta stare in chat con loro la sera fino a mezza notte:D).

[afxgroup]

non è così. Perchè su OWB ci sono delle cartelle per ogni parte "non-standard". Ad esempio, gtk, sdl, win, amigaos4. Nulla gli vietava di aggiungere morphos (come ha fatto nel suo sorgente). E avrebbe aggiunto nelle parti comuni a tutti gli OS i soliti #if PLATFORM(MORPHOS) etc etc.
Lui avrebbe usato MUI, noi REACTION. non cambiava nulla e non gli venivano sicuramente delle crisi di insonnia..
Stessa cosa per AROS che ha proprio un trunk tutto suo!
E ora sono costretto a mandare patches che anche se joerg non ha messo (perchè sono successive alla sua dipartita..) ci sarebbero state per gli altri OS. Per non parlare della parte del plugin.
Ve l'ho detto non si tratta della GUI si tratta della collaborazione

[ShInKurO]

non è così. Perchè su OWB ci sono delle cartelle per ogni parte "non-standard". Ad esempio, gtk, sdl, win, amigaos4. Nulla gli vietava di aggiungere morphos (come ha fatto nel suo sorgente). E avrebbe aggiunto nelle parti comuni a tutti gli OS i soliti #if PLATFORM(MORPHOS) etc etc.

Ho scaricato i (suoi) sorgenti stamattina, ha fatto appunto come hai descritto, e cioè ha creato delle cartelle per ogni parte non standard. Non ho capito dove sta il problema... puoi spiegarti meglio per favore? :)

Lui avrebbe usato MUI, noi REACTION. non cambiava nulla e non gli venivano sicuramente delle crisi di insonnia..

Il problema è che non ha aggiunto queste cose nel tree della sandlabs, o sbaglio?

[afxgroup]

infatti il problema è che non c'è nessuna parte nel trunk di sand-labs. E nemmeno per le parti comuni che sono nel codice stesso.

[ShInKurO]

infatti il problema è che non c'è nessuna parte nel trunk di sand-labs. E nemmeno per le parti comuni che sono nel codice stesso.

In effetti non sarebbe poi molto complicato visti i sorgenti, ma sei sicuro che alla sandlabs accettino facilmente le modifiche?

Io ho una conoscenza di C++ puramente didattica, ma se mi dici come compilare OWB su OS4 potrei aiutarti se ne sono in grado...

[afxgroup]

alla Sand Labs accettano modifiche senza problemi. Basta aprire un ticket. E' normale che prima ci diano un'occhiata. Ma se vanno bene le pubblicano.
Il problema di compilare OWB, oltre che alle eventuali modifiche al codice sono le dipendenze. Devi fare in modo di avere un SDK come si deve con tutto configurato bene e un cross compiler se non vuoi stare un giorno a compilarlo..
Per il resto è semplice..

[Fogg_80]

alla Sand Labs accettano modifiche senza problemi. Basta aprire un ticket. E' normale che prima ci diano un'occhiata. Ma se vanno bene le pubblicano.
Il problema di compilare OWB, oltre che alle eventuali modifiche al codice sono le dipendenze. Devi fare in modo di avere un SDK come si deve con tutto configurato bene e un cross compiler se non vuoi stare un giorno a compilarlo..
Per il resto è semplice..

Puoi dirci tu cosa usi, amidevcpp o altro e condividere o spiegare la configurazione in modo che giovani volonterosi come Shinky possano aiutare la comunita' ?

[afxgroup]

io su Windows uso cygwin + Textpad per compilare mentre su mac uso la shell del mac + Textwrangler.. nessun ambiente di sviluppo.. tutto a manina..
Quindi per compilare OWB bisogna innanzitutto crare un cross compiler funzionante ad hoc, mettere tutte le dipendenze ed usare una bella stringa con CMake che ho preparato..

[ShInKurO]

io su Windows uso cygwin + Textpad per compilare mentre su mac uso la shell del mac + Textwrangler.. nessun ambiente di sviluppo.. tutto a manina..
Quindi per compilare OWB bisogna innanzitutto crare un cross compiler funzionante ad hoc, mettere tutte le dipendenze ed usare una bella stringa con CMake che ho preparato..

Mi viene più pratico su Windows, programmare con il MacBook non è proprio ideale :)
Quindi in sostanza devo avere installato cygwin, installare i crosscompiler di zerohero, e testare le eventuali compilazioni per OS4 e MOS?