JavaScriptCore portato sotto aros

[afxgroup]

di parser CSS ne esistono circa 2-3 trilioni in giro.. il problema (ora ammazzo la tastiera e il minimac...) è che poi bisogna creare un motore di rendering ad hoc.. è quella la cosa difficile..

[AmigaCori]

di parser CSS ne esistono circa 2-3 trilioni in giro.. il problema (ora ammazzo la tastiera e il minimac...) è che poi bisogna creare un motore di rendering ad hoc.. è quella la cosa difficile..

[OT]
vedo che lo switch funziona alla grande!
[/OT]

[clros]

di parser CSS ne esistono circa 2-3 trilioni in giro.. il problema (ora ammazzo la tastiera e il minimac...) è che poi bisogna creare un motore di rendering ad hoc.. è quella la cosa difficile..

Dettaglia:cosa ti manca?

[afxgroup]

che vuoi sapere di più di quello che abbiamo scritto decine di volte e che hai scritto anche tu?
ve lo ripeto.. per ora la soluzione più veloce sarebbe quella di usare X11.. è inutile per ora reinventare la ruota.. quando (?) ci saranno più utenti e più programmatori nel mondo amiga (...) forse le cose cambieranno..

[riko]

di parser CSS ne esistono circa 2-3 trilioni in giro.. il problema (ora ammazzo la tastiera e il minimac...) è che poi bisogna creare un motore di rendering ad hoc.. è quella la cosa difficile..

Ma infatti non è questione di 'parsing', è questione di 'interpretazione'.
In generale scrivere un parser è una cosa noiosa e basta :)

Tra l'altro il problema è che i CSS non riguardano solo formattazione, ma anche posizionamento.

[clros]

Ma infatti non è questione di 'parsing', è questione di 'interpretazione'.
In generale scrivere un parser è una cosa noiosa e basta :)

Tra l'altro il problema è che i CSS non riguardano solo formattazione, ma anche posizionamento.

Cosa intendi per "interpretazione"?

[AmigaCori]

che vuoi sapere di più di quello che abbiamo scritto decine di volte e che hai scritto anche tu?
ve lo ripeto.. per ora la soluzione più veloce sarebbe quella di usare X11.. è inutile per ora reinventare la ruota.. quando (?) ci saranno più utenti e più programmatori nel mondo amiga (...) forse le cose cambieranno..

in effetti siete 4 gatti a programmare per OS4.0...sicuramente la situazione cambiera' quando questo maledetto OS4.0 sara' disponibile a chiunque voglia.

Certo che e' da pazzi la situazione: gente che VUOLE comprare HW + OS ma non ha la possibilita'...assurdo

[clros]

Certo che e' da pazzi la situazione: gente che VUOLE comprare HW + OS ma non ha la possibilita'...assurdo

Infatti: è proprio assurdo!

Da prendere a mazzate McEwen

[Amiga Supremo]

Certo che e' da pazzi la situazione: gente che VUOLE comprare HW + OS ma non ha la possibilita'...assurdo

Infatti: è proprio assurdo!

Da prendere a mazzate McEwen

E NON soltanto lui...

[riko]

Cosa intendi per "interpretazione"?

Beh, un interprete è un oggetto che prende un 'programma' in un dato linguaggio in input e da un output 'eseguendo' il programma.

Normalmente siamo abituati a pensare ad un 'linguaggio' come ad un linguaggio 'turing-completo' (vedi C, Perl, PHP). E ad un interprete come un programma che legge tale programma e ha un output.

In effetti l'output non deve necessariamente essere roba 'ascii'. Può essere un comportamento, un'immagine. Io normalmente sono molto formale nelle mie definizioni.

Per cui vedevo il browser come un interprete che prende appunto un sorgente (x)html + css e la renderizza. L'output è invece che testo quello che vedi a schermo e tutto.

Ecco, pensa a Logo (quello con la tartarughina). Hai il tuo interprete e i tuoi comandi hanno un 'effetto grafico'. Il browser non è completamente diverso (solo molto più complesso). Non solo, in questo modello aggiungere Javascript (da un punto di vista concettuale sposta solo la potenza del tutto -- che diventa turing completo --).

Oh, insomma, se non è chiaro quello che ho detto, non è grave. Non è nulla di trascendentale.
Il succo è che sono perfettamente d'accordo con afxgroup, solo che io vedo appunto il processo di rendering come un processo di 'interpretazione' (in senso tecnico proprio) dei dati.

Avrei detto invece che il mio script 'compilava' le pagine web in un pdf, analogamente a quando parliamo di 'compilare' un sorgente latex (anche se li in effetti non saprei ben dire dove tracciare il limite fra interpretazione e compilazione).

[clros]

Io normalmente sono molto formale nelle mie definizioni.

Me ne sono accorto!

Per cui vedevo il browser come un interprete che prende appunto un sorgente (x)html + css e la renderizza. L'output è invece che testo quello che vedi a schermo e tutto.

Si, adesso mi è chiaro.

Solo che io "spezzavo" mentalmente il procedimento in almeno 3 parti:
l'interpretazione, che a partire dal sorgente html crea l'albero con i vari elementi (ecco, forse confondo la definizione con quella di parsing), dall'albero creare i singoli elementi (grafici) della pagina basandosi su eventuale codice CSS e infine aggiungere tutti questi elementi ad una finestra grafica, combinandoli opportunamente tra loro.

[ShInKurO]

Si può avcere, anche a grandi linee, un elenco delle classi MUI che vengono usate da sputnik e che sono essenziali?

Su questo non posso risponderti perchè non ho MOS, però basta che scarichi l'ultima beta di MUI4 che contiene il nuovo SDK... leggilo e dimmi cosa NON useresti per implementare un browser :-)

[riko]

Solo che io "spezzavo" mentalmente il procedimento in almeno 3 parti:
l'interpretazione, che a partire dal sorgente html crea l'albero con i vari elementi (ecco, forse confondo la definizione con quella di parsing), dall'albero creare i singoli elementi (grafici) della pagina basandosi su eventuale codice CSS e infine aggiungere tutti questi elementi ad una finestra grafica, combinandoli opportunamente tra loro.

La prima fase è proprio il parsing. Per il resto non ho idea del modo più efficiente per fare le cose ne di come sono fatte in effetti.