Webbrowser für 8-Bit-Rechner

Zitat von Hexworx

O.K., aber wofür braucht's dann noch das andere Hamburger-Strichel-Symbol?

Das andere Menü mit Hamburger-Icon war ein beispielhaftes Menü auf der Website, während das M-Menü das Hauptmenü des Browsers ist. Gerade um das besser zu unterscheiden, hatte ich das M-Symbol (exklusiv) für das Browser-GUI entworfen.

Zitat von Hexworx

Ging einfacher, als zunächst befürchtet (wegen des blödes Bitmap-Aufbaus) und sieht schon schick aus:

Das finde ich auch. Toll, dass es dir so wenig Kopfschmerzen bereitet hat, das umzusetzen. Ich werde irgendwann einen kleinen Font mit den GUI-Elementen anlegen, den man dann hinmappen kann, wo immer man ihn hin haben möchte.

Zitat von Chagizzz

Aber wo zieht man da die Grenze? [bei den Verschachtelungen]

Das weiß ich auch noch nicht. ich werde mal in mich gehen.

Zitat von Chagizzz

Ggf. wäre ein zu-/abschalten dieser farblichen Hervorhebung vielleicht denkbar - falls man mal sonst gar keinen Sinn in die Anordnung der Seite bekommt. Oder wenigstens einen Wechsel zwischen hell-/dunkelgrau. Farblich abgehoben und doch ordentlich.

Vielleicht muss man das auch erstmal mit einigen Seiten ausprobieren, um zu gucken, wo und wie man das optimieren kann.

Zitat von Chagizzz

Ich denke, [der Terminal-Mode] wird einfach eine Option bleiben, die standardmäßig eben nicht aktiviert ist.

Ich habe da überhaupt nichts gegen. Nur als Default hätte ich es eher doof gefunden – aber optional gerne.

Zitat von Chagizzz

Was Bilder angeht, müsste der Browser selbst auch mitteilen, ober die Bilder tatsächlich als <img...> Tag haben und nachladen möchte (sofern er irgendwie dazu in der Lage sein sollte) oder ob diese ggf. als LINK dargestellt werden - wenn es irgendeine Möglichkeit gibt diese Bilder darzustellen.

Ich hatte da irgendwann mal verschiedene Konzepte erwähnt. Momentan würde ich sagen, dass sich der Retro-Browser gegenüber dem Proxy ausweisen sollte (wie es aktuelle Browser ja auch tun). Er gibt preis, um welchen Client-Rechner es sich grundsätzlich handelt und nennt bestimmte Fähigkeiten (Bitmap vs. Textmode, RAM-Ausstattung, Anbindungs-Geschwindigkeit ...). Der Proxy passt dann seinen Output darauf an. Bei einem Amiga würde er Grafiken herunter rechnen und auf der Seite platzieren, beim C64 gäbe es Bilder nur "auf Anfrage", bei einem PET noch nichtmal die. Im HTML-Text gibt es dann nur einen Link mit Alt-Tag. Der Browser könnte dann, wie in einem meiner Mockups, einen Rahmen um den Alt-Namen legen und bei Klick das (schon vorher konvertierte) Bild fullscreen laden.

All das wäre in sauberstem HTML möglich. Mal handelt es sich im IMG-Tags, mal um verlinkte Bilder und bei fehlenden Grafikfähigkeiten (PET ...) steht da halt nur noch die ALT-Bezeichnung der Grafik – ohne Link.

Zitat von Hexworx

Die Doppel-Zeilen-Geschichte ist ja auch sehr hilfreich für die Menü-Darstellung, so wie du sie gezeichnet hast.

Was gibt es denn für Vorgaben für die Icons? Dürfen die höher als 8 Pixel sein oder ist ein klassischer C64-Char die Grenze? (Mein Reload-Button ist 9 Pixel hoch, was ja bei 16 Pixeln Höhe des blauen Kopfbereichs normal kein Problem darstellt.)

Zitat von Chagizzz

Was Bilder angeht muss ich komplett passen, habe ich keinen Plan.

Kein Problem. Es gibt dafür teils Bibliotheken, die man einfach einbinden kann, und was da noch fehlt, kann uns bestimmt jemand basteln, wenn wir soweit sein sollten. Bis dahin kannst du Bilder erst mal ignorieren.

Zitat von Chagizzz

Was ALT-Namen in den IMG Tags angeht, werden diese häufig immernoch nicht verwendet. [...] Ich würde dann vermutlich bei nicht Vorhandensein auf Proxyebene einen ALT-Namen erstellen (entweder anhand eines Titels oder des Dateinamens (ohne Pfad)).

Das klingt nach einem sinnvollen Plan.

Zitat von Hexworx

Der Button kann auch gerne 9 Pixel hoch sein (oder auch 13/16 was-auch-immer). Oder auch 16x16 Pixel groß. Wichtig ist nur, dass sie dann vertikal zentriert und aneinanderhängend gepixelt werden, quasi wie ein Tile.

Ich habe jetzt mal alle bisher gepixelten GUI-Elemente in ein PNG (mit C64-Palette, 256 x 12 Pixel) gepackt:

C64Browser-GUI-Font.png
Kannst du damit direkt etwas anfangen?

Zitat von Hexworx

Ja, Danke, hab sie alle drin und sind schon schick(er)!

Danke. Ist deine Technik auch in der Lage, den 16x16 Pixel Hintergrund eines Icons, wie von mir angedeutet, bei klick, Tab (oder sogar mausover) umzufärben?

Die Funktionen sind wahrscheinlich weitgehend selbsterklärend: Pfeil links/rechts dienen der Navigation in der "History", wobei man es beim C64 nicht übertreiben muss, was die Anzahl der gemerkten Einträge angeht. 8 sollten dicke reichen. Dann folgt der Geschwungene Pfeil, der einen Reload andeuten soll. Das X schließt die Seite (und öffnet eine, in den Prefs definierte, Startseite – da wir ja keine weiteren Fenster/Tabs haben) oder stoppt einen Seitenaufbau, solange er nicht beendet wurde. Auf der rechten Seite der URL-Zeile folgt dann das Pluszeichen, dass einen Bookmark anlegt und das M, welches weitere Menüpunkte (vielleicht speichern der aktuellen Seite als Text, öffnen der Bookmark-Liste, Einstellungen ...) anbietet.

Zitat von Hexworx

Hab' mir nur die Tage den Code etwas zerschossen

Das tut mir leid. Ich hoffe, dass du das schnell wieder repariert bekommst.

Zitat von Chagizzz

...das merken könnte doch auch der Proxy übernehmen.
...auch TABS könnte ggf. ein Proxy "offenhalten" (zwischenspeichern) und ohne wirklich neu zu laden neu senden.

Gute Idee. Aber ich wollte dem Proxy nicht zu viel Arbeit zuschieben – nicht dass der Proxy-Programmierer deshalb noch die Lust verliert.

Zitat von Chagizzz

Was evtl. noch fehlt, ist ein vor und zurück innerhalb einer sehr Quelltext intensiven Seite (die z.B. nicht in den Speicher eines c64 passt). Wobei das sinnvoller Weise über die seitliche Laufleiste erledigt werden könnte.

So hatte ich mir das auch gedacht. Eine Seite wird bis etwa zum Speicherlimit (vorher kundgetan, könnte ja auch eine REU vorhanden sein) auf den C64 geschoben und wenn man mit dem Scrollen ans vorläufige Ende stößt, dann schiebt der Proxy Daten nach (bzw. überschreibt die ältesten Daten).

Zitat von Hexworx

Jedenfalls keine wilde Baustelle.

Klingt gut.

Zitat von Hexworx

Das Wetter ist die Tage aber einfach zu schön, um daran rum zu basteln. Da treib' ich mich lieber im Garten rum

Das kann ich nachvollziehen.

So Jungs, die Tage werden wieder kürzer und das Wetter schlechter. Seit ihr mit irgendwas weiter gekommen? Habt ihr in absehbarer Zeit wieder mehr Zeit für das Projekt? (frage ich mal ganz vorsichtig in die Runde)

Zum einen hat sich an der Hardware-Front etwas getan. Wie ich in einem der WLAN-Threads herausfinden konnte, scheinen sich diese Billig-WiFi-Modems auf ESP8266-Basis sehr gut als C64/Internet-Schnittstelle zu eignen. Das kleine Board bekommt man für 3 (China) bis 8 Euro (Amazon), dazu noch eine Lochrasterplatine und ein Userport-Stecker – und man ist im Netz. TCP/IP-Stack ist da schon drin (spart uns Entwicklungszeit und C64-RAM), besser und billiger geht es eigentlich nicht.

Zum anderen kam ich über die Modems mit "thE rZA" ins Gespräch. Er hat mir zum Thema Proxy folgenden Link empfohlen: mitmproxy. Auf der Basis könnte man vielleicht auch schnell zu einem laufenden Proxy kommen, den man dann immer mehr filtern lässt. Ich will nicht sagen, dass komplettes Selberschreiben schlechter ist aber vielleicht kommt man so einfacher zum gewünschten Ergebnis. Kann man sich ja mal angucken.

Und last but not least macht es vielleicht Sinn, den C64-Client als nächstes dazu zu bringen, Text einzulesen und HTML zu interpretieren. Irgendwie ist es jetzt ja anscheinend erstmal Konsens, dass der Proxy HTML ausspucken wird. Hier findet man eine rudimentäre HTML-Übersicht. Die Befehle unter "HTML5-Grundgerüst sollte man 1:1 übernehmen", "Bereiche einteilen" kann man bis auf <nav> weglassen, "Text strukturieren" muss komplett rein, "Textstellen hervorheben" kann eigentlich bis auf <b>, <i> und <sup> (für die Zahlen 1, 2 und 3) raus, da der C64 den Rest eh nicht darstellen kann (oder sie re­d­un­dant sind). Der Bereich "Links, Verweise" macht Sinn, sind aber eh alles nur Spezifikationen von <a href>. Die 3 "Aufzählungs"-Tags sollten wir übernehmen (allein schon für die Menüs), "Bereiche definieren" benötigen wir nicht. Da der Proxy schon "Kommentare" rauswerfen sollte (um Speicher zu sparen), muss der Client sie eigentlich nicht interpretieren können und "Farben" haben in HTML ohnehin nichts mehr zu suchen.

Darüber hinaus könnte man <cite> für Zitate verwenden, <img src> für Bilder und <form>, <input type> (text, submit, radio, checkbox), <input name>, <textarea> und <select name> für Formulare.

Alles andere, wie <div>, <align>, <table>, <frame> usw. brauchen wir eigentlich nicht. Gefühlt wären wir also bei ca. 25 Befehlen.

Zitat von Chagizzz

Vielleicht können wir ja mal eine Liste der HTML-Tags zusammenstellen, die wir behalten wollen von denen wir glauben, dass wir diese darstellen können. Ich mache mal einen Anfang: ...

Eigentlich ist das fast schon vollständig. Der Proxy kann noch ein paar Tags zusammenführen. <strong> wird zu <b>, <em> zu <i>, <blockquote> zu <cite> ...

Das hier ist meine Zusammenfassung aller HTML-Tags, die der Retro-Browser beherrschen sollte. Der Proxy sieht dann zu, dass in den gelieferten Texten möglichst auch nichts anderes enthalten ist.

Mini HTML-Set:

<html> HTML Anfang
<head> Kopfbereich mit Meta-Infos
<meta charset="ISO-8859-15"> Definition des Encodings, andere Meta-Tags ignorieren
<title> Name der Seite (kann in der URL-Zeile dargestellt werden)
<body> Beginn der darzustellenden Seite

<h1> bis <h6> Überschriften und Unter-Überschriften, notfalls alle gleich darstellen
<p> Absatz
<br> Zeilenumbruch
<hr> Horizontale Trennlinie
<b> Bold
<i> Italic (auch wenn wir dafür keinen Font haben werden)
<sup> hoch gestellte 1, 2 und 3 (da im Font enthalten)
<cite> Zitat, einrücken oder farbig hinterlegen (evtl. weglassen)

<!-- Kommentar --> (einfach ignorieren, außer bei Keyword "menu")
<ul> Unsortierte Liste (oft für Menüs, sonst vorangestellte Bullets)
<ol> Sortierte Liste (durchnummerieren)
<li> Listeneintrag (Wenn kein Menü, dann ein Bullet davor schreiben)
<nav> Kann eine Liste von Links einschließen, die ein Menü bilden soll (evtl. weglassen)

<a href="ziel.html">Link</a> Link
<a href="#0001">Link</a> Durchnummerierter Link vom Proxy
<img src="bild.gif" alt="Haus"> Eingebettetes Bild, "alt" als Text anzeigen, Bild verlinken

<form action="script.php"> Formular-Anfang
<input type="text" name="name" size="30" maxlength="40"> Einzeiliges Textfeld
<input type="password"> Wie Text aber Sternchen statt Text
<input type="radio" name="Auswahl" value="item1" checked> Radio-Button (vorausgewählt)
<input type="checkbox" name="Auswahl" value="item1"> Checkbox
<input type="image" src="trash.png" alt="Mülleimer"> Grafik-Button
<input type="submit" name="action" value="Absenden"> Schickt die Formulareingaben an die "form action"-URL
<textarea cols="50" rows="10"> Mehrzeiliges Textfeld mit Größenangabe

Fast alle Tags haben ein schließendes Endtag, das mit einem vorangestellten Slash geschrieben wird
Tags ohne Endtag sind img, br, link, meta und input (sauber: den End-Slash mit in den Tag schreiben)
Tags, die der Browser nicht kennt, soll er ignorieren; unbekannte Angaben innerhalb von Tags ebenso.
Tags sind nicht case-sensitiv, also Groß- wie Kleinschrift behandeln
Folgt auf ein "<" eine weiteres "<" ohne, dass ein ">" kam, setzt der Browser es selber (fängt aber der Proxy schon ab)

Wenn man die unterschiedlichen Input-Typen zusammenfasst, kommen wir mit 20 bis 25 Tags hin. Ich finde das schon eine ordentliche Reduktion aufs Wesentliche.

Zitat von Hexworx

Echtes 'sup' & 'sub' ginge theoretisch aber auch. Ebenso 'del'.

Wegen mir gerne. Ich hatte auch den Fehler gemacht, manchmal zu sehr nur an den C64 zu denken. Die Befehlsübersicht oben soll ja eher als Anhaltspunkt für die Erstellung von Browsern auf allen möglichen Plattformen sein – und einem Atari-520ST fällt es sicher nicht schwer, einen Text durchzustreichen. Ich kann das also noch etwas erweiteren. Das sind die Befehle, die ankommen könnten. Was der Browser davon wie darstellt, muss der Programmierer selbst entscheiden. Er kann ja <i> ignorieren oder einfärben oder eben kursiv darstellen.

Zitat von Hexworx

Hmm, soll das HTML wirklich 1:1 durchgereicht werden? Wenn ja: Warum? Finde ich immer noch ziemlich unglücklich. Wie irgendwo vorher schon mal geschrieben, wäre es wohl für sämtliche 8-Bit-Maschinen wohl leichter entschlüsselbar/verdaulich, diese gleich zu vereinfachen (wie z. Z. noch mein '@@'-System).

Im Endeffekt müssen das die Programmierer unter sich auskakeln. Wenn der Client gerne irgendwelche proprietären Kommandos haben möchte und der Proxy die liefern mag, soll es mir auch recht sein. Ich sehe aber (nach einer skeptischen Phase) auch die Vorteile von einem HTML-Subset: Zum einen kann ein HTML-Subset-Browser auch ohne den Proxy im Netz surfen. Die Seiten sehen dann vielleicht shice aus und brauchen lange zum Laden – aber es würde notfalls gehen (halt wie bei Kontiki). Was ich aber wichtiger finde: Ich glaube, die Akzeptanz unter Programmierern auf anderen Plattformen wäre größer, wenn wir einen etablierten Standard (HTML, Markdown, WAP o.ä.) für die Kommunikation verwenden – und ein wichtiger Teilaspekt des Projektes ist aus meiner Sicht, plattformunabhängig zu bleiben. Ein drittes Argument für HTML ist, dass z.B. für frühe 16-Bit-Plattformen rudimentäre Webbrowser existieren – und die müssten nicht einmal umgebaut werden, um unseren Proxy zu nutzen. Sie wäre damit out-of-the-Box schneller und die Darstellung wäre wahrscheinlich sauberer (wenn auch weniger "rich").

Also, ich wäre weiterhin für offene Standards aber wenn ihr euch auf eine andere Kommunikation einigen könnt, will ich euch nicht im Wege stehen. Lieber mit @@-Kommandos als gar nicht (falls das die Option wäre). Wichtig ist, dass die oben von mir mit HTML beschriebenen Fähigkeiten (mindestens) unterstützt werden. Deinen bisherigen Kommandos sieht man an, dass sie für eine Textverarbeitung gedacht waren. Bei einem Browser geht es aber mehr um semantische Strukturierung als um Optik.

Zitat von Hexworx

Das würde schon verdammt fummelig und CPU-zeitraubend. Ein fehlendes ">" ginge auch gar nicht.

Der Proxy kann ja dafür sorgen, dass das nicht vorkommt. Wenn es aber der Browser zusätzlich abfangen kann (wie PC-Browser das auch tun), dann kann man damit besser auch mal ohne Proxy ins Web.

Zitat von Hexworx

Oder müsste dafür noch ein weiterer "Selfmade"-Proxy nachgeschaltet werden?

So wie ich das sehe, soll der das natürlich können – denn dafür sind Proxys nun mal da.

Zitat von Chagizzz

Sieht schlecht aus bei mir. Nicht ganz tot, aber ganz weit unten in der ToDo-Liste.

Das ist sehr schade.

Zitat von Chagizzz

DIV würde ich nicht so einfach wegstreichen wollen, da es "irgendwas" abgrenzt. Anfang und Endtag könnte man ggf. durch <br> ersetzen um irgendwie diese Abgrenzung beizubehalten.

Wir können <div> (ohne Klassenaufruf) auch drin lassen. Besser als ein <br> ist es allemal. Ich würde <div> halt in <p> umwandeln, weil es einem Absatz am nächsten kommt und <p> (im Gegensatz zu <div>) von Legacy-Browsern unterstützt wird. Aber meinetwegen lassen wir <div> als modernen Abschnittstrenner drin.

Zitat von Chagizzz

Da habe ich gar keine Lust mich mit zu beschäftigen... liegt aber eher an mir.

Schade. Ist aber nicht schlimm, wenn du meinst, es auch mit "Handarbeit" hinzubekommen. Ich dachte halt, ein fertiger Proxy wäre eine gute Basis, um Arbeit zu sparen. Und weil ja alle hier zu wenig Zeit haben ....

Egal, ich will ja nur eines: dass es irgendwann einen Proxy gibt, der die Seitenkomplexität und Datenmenge des Webs drastisch reduziert und einen Browser, der den Output versteht und darstellt. Guckt einfach, ob ihr eure Vorstellungen zusammen bekommt. Jede Lösung ist besser als keine.