Entwicklerunterstützung - Atari Browser

[Atari060]

Naja, mit Atari VNC hab ich ja auch Firefox auf dem Atari... ist aber halt nicht echt und deswegen indiskutabel

Da wär´ ich mir jetzt nichtmal soo sicher. Wir nehmen einen Gumstix oder Ähnliches plus einer Hydra, pappen ein hochoptimiertes Linux drauf, stecken das in eine Zigarettenschachtelgroße Box, und passen im Idealfall noch das Layout vom Browser & Co. ein bissl auf GEM an. Da drauf laufen dann alle erdenklichen Netzwerkklients + Printserver +USB Netzwerkfreigabe etc. etc. Am Atari wird dann MiNT-Net und Atari VNC installiert und der Treiber stellt am Minirechner ein auf welche Farbtiefe (SM124 bis ATI 9250) er das runterrechnen soll.  Das vermarkten wir dann als Atari "Network & USB Hardware Erweiterung" um 149,-  für jeden Atari ab 4 MB Ram.

Könnte genausogut wie bei der UltraSATAN funktionieren, wo auch niemand dran denkt daß da ein 400MHz ARM drinnen werkelt, …  Und so überbrücken wir erfolgreich die Zeit, bis unsere Lieblingsplattform wieder native aktuelle Browser & Co. aufweisen kann .

Wenn es eine "Hardwarelösung" AM oder IM Atari ist und kein extra Rechner in Form eines stromfressenden PCs ist und AVNC so umfunktioniert wird, dass man meint man startet eine native Software, dann geht das für mich absolut in Ordnung (vorrübergehend jedenfalls).

Ziel sollte aber ein eigenständiger Browser (oder wenigstens ein Port eines aktuellen Browsers) sein, denn sonst gebe ich Ingo Recht, denn warum sollte dann überhaupt noch daran entwickelt werden?

Mein Motorola Q hat 350 MHz und 96 MB Ram und darauf läuft Sykfire ein Browser mit Flash Plugin (youtube, webradio, etc) absolut flüssig. Sollte auch auf langsameren smartphones laufen, also denke ich, dass sowas - zumindest auf dem Coldfire - wenn nicht sogar auf der CT60 möglich wäre.

Auch ich bin für einen modularen Aufbau, so dass der reine HTML Browser auch auf den langsameren Ataris läuft. Allerdings bin ich der Meinung, dass dies nicht die größte Bewertung haben darf, denn wenn unsere Plattform überleben soll und zwar nicht nur als reines Hobby, dann müssen wir uns langfristig die 68k Zöpfe abschneiden... Das bedeutet ja nicht das Aus für die Retrogemeinde, aber einer zukunftsorientierten TOS, bzw. MiNT Entwicklung steht die Abwärtskompatiblität der Software mittlerweile arg im Wege.

Es ist schön, wenn Programme, wie z.B. atarICQ im Nachhinein (wieder) ST- kompatibel gemacht werden. Aber das Hauptaugenmerk darf das nicht sein.

Wir haben schnelle Rechner (Milan, Hades, CT60, Firebee) und wenn wir wollen dass es für die auch Software gibt, dann muss was passieren. Momentan kann ich alles was ich auf der CT60 machen kann auch (langsamer) im 030 Modus machen (abgesehen von Demos und Quake/Duke Nukem) und das darf meiner Meinung nach nicht sein!

[Mathias]

Bitte mein Vorschlag war jetzt nicht wirklich ultimativ ernst gemeint! Ich wollte nur darauf hinweisen daß mit der Miniaturisierung etliches machbar ist (Mein Palm war vor 8 Jahren schon so leistungsfähig wie mein Atari, …). Und ich denke bei entsprechender Sorgfalt bzgl. Atari-Umgebungsintegration ist schon einiges möglich daß dann auch Akzeptanz finden könnte.

Ich selbst bin eigentlich ein Verfechter von Abwärtskompatibilität! Also zumindest ab Standard-Falcon und PAK sollten neue Entwicklungen nutzbar sein. Wir haben einfach keine Basis die groß genug wäre ansonsten.

[Atari060]

Da geb ich Dir ja Recht - und z.B. spielmäßig wurde noch nichteinmal der Standardfalcon richtig ausgereizt...

Aber irgendwie muss man ja einen Anreiz schaffen, dass eine neuere - u/nd schnellere breite Basis geschaffen wird. Und wenn dann alles noch auf "08/15" Hardware läuft, dann gibt es wieder keinen Grund zum Umsteigen...

Ich denke, dass viele Falconbesitzer bereit wären auf ein schnelleres Pferd (=Firebee) zu setzen, wenn dies die selben Vorzüge besitzt (z.B. DSP). Wie gesagt, einen CT60 Rechner werde ich z.B. dann auf jeden Fall hergeben. Ideal wäre also, wenn die >300 CT60 Besitzer eine Firebee nehmen würden und ihre CT60 dann weitervererben 

Nein, ist jetzt nur Spass, aber schau, wir hatten mit dem Milan/Hades wirklich super Rechner, für die es praktisch 0 spezielle Software gab... Running Milan, oder Legends of Espen waren sehr vielversprechend, aber leider wurde ja nix draus

[Arthur]

Ich bestreite mal das ein DSP (wenn er so alt ist) heute noch jemanden vom Hocker reißt. Sicherlich hat er damals noch seine Berechtigung gehabt. Heute macht er nur noch aus Kompatiblitätsgründen sinn, damit evtl. vorhandene Software auch auf der Firebee läuft. Würde den glatt weg lassen wenn es nach mir ginge. Schnelle Festpltten, hochauflösende Grafik und Netzwerk sowie endlich funktionierendes USB sind mir viel wichtiger.

[tuxie]

Hallo,

@Arthur da gebe ich dir nur zum Teil recht. Ich selbst habe ihn auch nich vermisst gehabt. ABER es gibt wohl auch noch heute Anwendungen in denem ein Digitaler Signal Prozessor verwendet wird. Man muß es ja so sehen, der DSP hat eine Schnittstelle was ihn ultimativ macht, das es heut zu tage schnelere und leistungsfähiger gibt. Aber ein DSP ist auch heute noch in bestimmten bereichen notwendig. Ich ziele jetzt hier auf den Musikbereich.

[m0n0]

Ich denke das die Atari Community einfach zu klein ist um einen aktuellen Webbrowser "herzustellen"... Andere Software kann evt. von einem alleine Bewerkstelligt werden, aber einen ganzen Browser "nebenbei & alleine" zu entwickeln das geht nicht so recht. Es müssten ein paar Atari Leute daran Programmieren,... aber davon gibt es ja nicht so viele >

So ein Browser verlangt schon vieles an know-how... und es ist besser wenn man sich auf einen Bereich speziallisieren kann, aber ein Browser hat viele Ecken und Kanten, mit denen man sich ja nicht immer und überall beschäftigen kann

Wenn es einen Weg geben würde eine Gruppe zu finden die einen aktuellen Browser "hervorzaubert" - dann würde ich an dem Weg interesse haben

Und abwärtskompatibilität ist wirklich ein "Hindernis" ... wenn sowas als "Leitlinie" gillt... dann hat man immer ein schlechtes Gewissen wenn man etwas machen würde was Abwärtskompatibilität bricht, obwohl es doch eigentlich ganz gut ist...

[tuxie]

Was haltet ihr einfach mal davon, bei den Highwire Entwicklern anzufragen. Wenn dies mehrere tun, dann tut sich sicher mehr. Ich meine wir reden hier nur und keiner tut was.

[michschmi]

Hab jetzt keine Statistiken zur Hand, aber vom meinem Gefühl her würde ich sagen das die Amigacommunity einfach größer ist. Auch scheint es mir auf der Amigaseite mehr Clone zu geben die ausreichend Resourcen dafür mitbringen. Mir selbst reicht das Tempo von Higwire auf dem Atari TT und Falcon mit 32MHz aus. Es geht zwar recht gemütlich zu aber für mich reicht es. Wie ihr wisst werden hier nicht alle Webstandards unterstützt. Ein neuer Browser sollte vielleicht modular aufgebaut werden, so das selbst ein Mega ST oder STE noch läuft. Später kann man für die Boliden ja eine spezielle Version anbieten. Er sollte auch unter Plain TOS funktionieren. Ob sich eine Browser nur für die paar CTXX User lohnt das bezweifle ich. Die Portierung eines anderen Browsers auf die CTXX sollte aber auf grund der Rechenpower moglich sein.

wenn ich mich recht entsinne, hatten die Amiga Leute nach der Ausgliederung der Amiga Inc. aus  Comodore noch bis mind 2002 professionelle Unterstützung. Von Amiga Inc. wurde die Erweiterung des OS (bis 3,5 soweit ich weiß) und die Umstellung auf PPC-Prozessoren betrieben. Da war alles noch unter enem Dach, während bei Atari 1996 alles den Bachh runter ging, nach dem Verkauf an JTC. Da wurde alles verteilt. SW-Entwicklung wurde nur  noch von wenigen Enthusuiasten betrieben, von denen die meisten aber nach 2000 die Plattform verliessen (es war halt leider eine zu kleine Anwenderschaft und wirklich viel Geld verdienen konnte man mit Atari-SW auch nicht (mehr)). Aber was am Wichtigsten war: Die Hardware-Entwicklung stagnierte total. Bei Falke Media wurde versucht, die HW-Entwicklung mit dem Milan neu zu beleben und für eine kurze Zeit war Atari der PC-Welt fast ebenbürtig (in 1999 gab es fast nichts (ausser super tolle Direct-X-Grafik-Spiele), das ich nicht auch mit dem Milan erledigen konnte (fast jede I-Net-Seite war mit Draconis darstellbar; selbst die Alias-Bennung einer Mai-Adresse bei T-Online war kein Problem).
Leider stagnierte schon bereits in 2000 der Fortgang und die Entwickler wendeten sich von der Atari-Schiene ab.
Und heute jemanden, wue Jens Heitmann für Programm-Entwicklung "zurückzuholen" ist fast unmöglich, den wie bei vielen von uns auch, spielen längst andere Dinge im (Berufs-)Leben eine wichtigere Rolle.
Es klang bereits in einem frühren Post an: Die Unterhaltung ist dieselbe, wie wir sie bereits 2006 oder 2008 hier geführt haben.
Es geht leider so gar nicht voran....

[Atari060]

Stimmt leider Ohne Software kein Sinn für neue Hardware...

[m0n0]

Was haltet ihr einfach mal davon, bei den Highwire Entwicklern anzufragen. Wenn dies mehrere tun, dann tut sich sicher mehr. Ich meine wir reden hier nur und keiner tut was.

Auf der Mailing Liste ist kaum noch was los. Ich denke nicht das es an der Nachfrage liegt, sondernd an fehlender Zeit bzw. fehlenden Entwicklern. Die meisten "kern" Entwickler haben sich ja auch vom Projekt verabschiedet...

[draconis1]

Wer C kann sollte vielleicht doch mal bei Jens anfragen (Draconis) (Klick zum Eintrag im Forum)

[Atari060]

Draconis ist meiner Meinung nach immer noch der fortgeschrittenste Browser... leider bekomme ich ihn auf dem 060 nicht ordentlich zum Laufen

[m0n0]

Draconis ist meiner Meinung nach immer noch der fortgeschrittenste Browser...

Ok, der hat javascript, aber dafür kein CSS,...
highwire aber schon...

Wenn Draconis auch noch einen renderer besitzt der die HTML Struktur in einer Baumstruktur ablegt und dann die einzelnen HTML Elemente der Baumstruktur parst & rendert wäre es ein besserer Kandidat für die Implementierung von JavaScript als Highwire... Weil man dann das DOM zur Laufzeit verändern könnte

In highwire muss man da, soweit ich das gepeilt habe, den renderer schick umschreiben.... was wohl niemand machen will ^^

[UdoWoy]

um 2000 herum hatte ich "Draconis 1.7" auf meinem Falcon mit der ersten von Rudolphe selbst auf der Messe eingelöteten Centurbo-Erweiterung laufen.     Leider habe ich diesen Falcon nicht mehr - bin bei diesem Thema auch nicht ganz auf dem Laufenden. 

[guest1994]

Ok, der hat javascript, aber dafür kein CSS,...
highwire aber schon...

Falsch: Die unvollendete 2.0 hat bereits partiellen CSS Support.

Siehe z.B.

http://draconisatari.cvs.sourceforge.net/viewvc/draconisatari/src/web2.0/STYLES.H?revision=1.1&view=markup

Wenn Draconis auch noch einen renderer besitzt der die HTML Struktur in einer Baumstruktur ablegt und dann die einzelnen HTML Elemente der Baumstruktur parst & rendert wäre es ein besserer Kandidat für die Implementierung von JavaScript als Highwire... Weil man dann das DOM zur Laufzeit verändern könnte

Das ist aus historischen Gründen nicht ganz der Fall. Gerade in den früheren RAM beschnittenen Zeiten hätte das bedeutet, das zunächst mal die Seite (xxx Bytes) + ein Klone in DOM-Treeformat im RAM gelegen hätte. Deswegen werden zu jeden Tag nur rudimentäre Informationen gespeichert.

Generell kennt aber jedes Tag seinen Anfang und Ende und das sollte sich auch als DOM umarbeiten lassen.

[m0n0]

Das ist aus historischen Gründen nicht ganz der Fall. Gerade in den früheren RAM beschnittenen Zeiten hätte das bedeutet, das zunächst mal die Seite (xxx Bytes) + ein Klone in DOM-Treeformat im RAM gelegen hätte. Deswegen werden zu jeden Tag nur rudimentäre Informationen gespeichert.

Ich habe auch versucht mir das zu erklären und ich bin auch zu diesem Schluss gekommen, jedenfalls teilweise. Man könnte aber ja auch nicht mehr benötigte Teile des Dokument-Speichers wieder freigeben...

Ein anderer Punkt ist die Geschwindigkeit, bei einem Tree Model muss erstmal das Dokument geparst werden und dann würde ein zweites Parsen des trees stattfinden + rendering.

Generell kennt aber jedes Tag seinen Anfang und Ende und das sollte sich auch als DOM umarbeiten lassen.

Naja, ich habe an JavaScript elemente wie z.b. mydiv.innerHTML="<b>text</b>"; gedacht, oder an sowas wie div.innerHTML = div.InnerHTML + "eine geänderte website";

das wäre natürlich blöd wenn man deswegen die komplette page neu rendern muesste ... zumal so ein rendering vorgang bei älteren Ataris ja nicht gerade schnell von statten geht

[Mathias]

Falsch: Die unvollendete 2.0 hat bereits partiellen CSS Support.

Hallo Jens, schön von Dir zu lesen!

Ganz direkte Frage. Was schätzt Du wie lange dauert es "Dein" Paket auf wirklich aktuellen Stand zu bringen. Und wieviel kostet es wenn Du dafür unbezahlten Urlaub von Deinem derzeitigen Brot-Job nimmst?

[guest1994]

Das ist aus historischen Gründen nicht ganz der Fall. Gerade in den früheren RAM beschnittenen Zeiten hätte das bedeutet, das zunächst mal die Seite (xxx Bytes) + ein Klone in DOM-Treeformat im RAM gelegen hätte. Deswegen werden zu jeden Tag nur rudimentäre Informationen gespeichert.

Ich habe auch versucht mir das zu erklären und ich bin auch zu diesem Schluss gekommen, jedenfalls teilweise. Man könnte aber ja auch nicht mehr benötigte Teile des Dokument-Speichers wieder freigeben...

Ein anderer Punkt ist die Geschwindigkeit, bei einem Tree Model muss erstmal das Dokument geparst werden und dann würde ein zweites Parsen des trees stattfinden + rendering.

Korrekt. Obwohl man da evtl. im ersten Arbeitsschritt ein paar dinge vielleicht sowieso gleich mit erledigen kann, so dass vielleicht nur noch ein minimaler zusätzlicher Renderingprozess nötig ist (Tabellen z.B.)

Generell kennt aber jedes Tag seinen Anfang und Ende und das sollte sich auch als DOM umarbeiten lassen.

Naja, ich habe an JavaScript elemente wie z.b. mydiv.innerHTML="<b>text</b>"; gedacht, oder an sowas wie div.innerHTML = div.InnerHTML + "eine geänderte website";

das wäre natürlich blöd wenn man deswegen die komplette page neu rendern muesste ... zumal so ein rendering vorgang bei älteren Ataris ja nicht gerade schnell von statten geht

Genau dafür. Wie gesagt, wenn es nicht auf den Speicher ankommt wäre das der Weg und das ließe sich umarbeiten.

Generell wurden auch die verschiedenen Browseralternativen nicht ausschließen. Ich würde allerdings für eine Portierung eine der Mobile Varianten in Erwägung ziehen. z.B. WebKit for Mobile. Die sind meisten deutlich weniger Speicherhungrig, auf schlappe Prozessoren ausgelegt und haben einen kleineren Sourceumfang. Würde aber wahrscheinlich trotzdem bedeuten, dass nur aktuelle HW eine Zielplattform ist. Mit gcc und Mint sollte das aber u.U. machbar sein. Besonders bei Webkit handelt es sich ja um das reine Rendering, so dass das GUI drum rum lediglich hinzugebaut werden müsste.

Machbarkeit?

[guest1994]

Falsch: Die unvollendete 2.0 hat bereits partiellen CSS Support.

Hallo Jens, schön von Dir zu lesen!

Ganz direkte Frage. Was schätzt Du wie lange dauert es "Dein" Paket auf wirklich aktuellen Stand zu bringen. Und wieviel kostet es wenn Du dafür unbezahlten Urlaub von Deinem derzeitigen Brot-Job nimmst?

Unmöglich und sicherlich unbezahlbar.

[m0n0]

Generell wurden auch die verschiedenen Browseralternativen nicht ausschließen. Ich würde allerdings für eine Portierung eine der Mobile Varianten in Erwägung ziehen. z.B. WebKit for Mobile. Die sind meisten deutlich weniger Speicherhungrig, auf schlappe Prozessoren ausgelegt und haben einen kleineren Sourceumfang. Würde aber wahrscheinlich trotzdem bedeuten, dass nur aktuelle HW eine Zielplattform ist. Mit gcc und Mint sollte das aber u.U. machbar sein. Besonders bei Webkit handelt es sich ja um das reine Rendering, so dass das GUI drum rum lediglich hinzugebaut werden müsste.

mit GCC... das meinte ich mit "die Rückwärtskompatibilität steht im Wege" ... bei HW ist es ja z.b. so das auch compiler wie lattice C und pure C unterstützt werden, aber das bringt auch viele Probleme mit sich... z.b. können die Libs die von GCC kompiliert werden von keinem der anderen Compiler genutzt werden das heisst ALLE source müssen auch mit pure C kompilierbar sein Ob das nun mehr Entwickler-Einsatz garantiert als wenn man mehr features aber nur gcc ermöglicht, ist fraglich. Aber ich merke es bei der Java Script library..., es ist eher nervig das teil PureC kompatibel zu machen BUS Error beim Garbage collector, na toll mit GCC lief die Kompilierung/laufzeit ohne auch nur eine Zeile code zu verändern... und es war lauffähig auf einem normalen ST...

WebKit werde ich mal anschauen... aber ich glaube aus irgend nem grund ist das nicht in Frage gekommen, glaube ich.