Webbrowser für 8-Bit-Rechner

Zitat von Chagizzz

Im Falle von HTML wäre das auch auf echten Browsern anzusehen. Dein "Format-Modus" Zeichen wäre also ein <. Aus sowas wie
<span class="icon icon16 icon-bell-alt"> würde dann eben nur <span> werden, d.h. der Client müsste eben nur das TAG lesen und entscheiden, was weiter passiert.Im Falle von <a href...> oder <img src=...> kommen da noch ein paar Informationen hinzu, die der Proxy sauber in festgelegter Reihenfolge übermitteln würde (auch wenn sie vorher anders aussahen).Schließende > müssen selbstredend Proxyseitig ergänzt werden. Schwieriger wird es vielleicht bei geschachtelten TAGS

Hab' mir diese div/span-Geschichte vorhin erstmals angelesen. Die reinen Befehle sehe ich noch halbwegs entspannt, aber die vielen zusätzlichen/vielen/langen Infos/Daten nicht. Für mich sieht das nach min. weit >75% überflüssigem Kram aus, der an den Client übergeben würde.

Beispiel:

"<tr style="background:#cccccc;">"

würde 'bei mir' sinngemäß aussehen '@@C0c' (schwarze Schrift auf grauem Grund). 32 vs. 5 Bytes. Soll ein Client das runterbrechen müssen? Allein diesen einzelnen Befehl zu verwursten, wäre schon eine wahnsinnge Unmenge an Code.

Zitat von Retrofan

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.

Ja, aber die HTML-Datenflut ist ja für alle angedachten Ziel-Systeme quasi tödlich. Wenn man sich nur mal diese kleine C64-Wiki-Seite anschaut: https://www.c64-wiki.de/wiki/SEI . Was einem da allein an HTML-Code-Wust entgegen schlägt... Und ich blicke da keinerlei Formatierungen (weil in CSS? Oder wo stecken die? Z. B. für die Tabellen). Wie soll das funktionieren? Soll der 8-Bit-Client das alles selbst generieren? Klingt für mich nunmehr nahezu unmöglich.

Zitat von Retrofan

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").

Weiß nicht, ob man die 16-Bitter hier wirklich berücksichtigen muss.

Zitat von Retrofan

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.

Stimmt natürlich. Das ist zunächst immer noch mein Haupt-Augenmerk. Das möchte ich erstmal sauber am Laufen haben.

Ich sehe nicht das Problem, z. B. die o. g. C64-Wiki-Seite auf dem 64er (ähnlich) darzustellen, aber nicht mit ankommendem (purem oder nur etwas gefiltertem) HTML-Code. Das wird wohl auf keinem 8-Bitter ordentlich und halbwegs erträglich schnell ablaufen/verarbeitet werden können.

Kann mich gerne jemand eines besseren belehren, aber ich habe irgendwie doch eingesehen, dass das evtl. doch eine (wenn auch gut gedachte) Totgeburt sein könnte . Gute Mock-Ups/Ansätze hin oder her.

Ich bastel jetzt erstmal (für mich) weiter am "TYPEWRITER-XY" und freue mich, wenn das mal soweit rund läuft. Ohne einen (Plattform-abhängigen) Super-Mörder-Proxy dazwischen sehe ich das Ding nunmehr doch als nahezu unmachbar an. Oder?

Ich melde mich dann auch erstmal von dem Projekt ab. Würde aber auch sofort wieder drauf aufspringen, wenn die angesprochenen Problemchen aus der Welt sind (oder ich eben doch zu negativ denke). Wie auch immer.

Zitat von Retrofan

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.

<p> ist deutlich besser, stimmt. Auch DIV lassen ist wohl besser als BR.

Zitat von Retrofan

. Ich dachte halt, ein fertiger Proxy wäre eine gute Basis, um Arbeit zu sparen.

... genau da liegt das Problem bei mir. Ich arbeite mich ungern in sowas ein um es dann irgendwie doch so zu biegen, wie ich es nutzen möchte. Aber vielleicht will ja jemand anderes damit arbeiten.

Zitat von Hexworx

Beispiel:

"<tr style="background:#cccccc;">"

würde 'bei mir' sinngemäß aussehen '@@C0c' (schwarze Schrift auf grauem Grund). 32 vs. 5 Bytes. Soll ein Client das runterbrechen müssen? Allein diesen einzelnen Befehl zu verwursten, wäre schon eine wahnsinnge Unmenge an Code.

Neee, da ist Dir was entgangen. Der Proxy macht eben genau daraus ein <tr>, schmeisst also alles andere weg, was der Browser sowieso nicht interpretiert.
Farben hatten wir gesagt, sollten eher ignoriert werden, da die vom Endgerät ohnehin nur sehr begrenzt dargestellt werden können. Das würde dann wohl zum Teil zu unlesbaren Farbkombinationen führen. Ein <tr class="hintergrundfarbe.css"> würde ohnehin nicht interpretiert. Dann würden also manche Farbinformationen übernommen, andere nicht.

Das SPAN Beispiel war ja auch nur wild aus dem Quelltext des Forums kopiert, weil ich damit klarstellen wollte, dass der Proxy nur noch das liefert, was der Browser auch braucht.
Mit sowas wie

(auch hier aus dem Quelltext des Forums) braucht man den Browser nicht zu füttern. Das wäre dann zu einem einfachen <li> vereinfacht. Auch wenn das <li> dann am Ende wohl keinen Sinn mehr macht.

Zitat von Hexworx

Ja, aber die HTML-Datenflut ist ja für alle angedachten Ziel-Systeme quasi tödlich. Wenn man sich nur mal diese kleine C64-Wiki-Seite anschaut: c64-wiki.de/wiki/SEI . Was einem da allein an HTML-Code-Wust entgegen schlägt... Und ich blicke da keinerlei Formatierungen (weil in CSS? Oder wo stecken die? Z. B. für die Tabellen). Wie soll das funktionieren? Soll der 8-Bit-Client das alles selbst generieren? Klingt für mich nunmehr nahezu unmöglich.

Genau die HTML-Datenflut erhält der Browser bei Nutzung des Proxys ja nicht. Javascript, CSS, Kommentare, nicht darstellbare HTML-TAGS usw... alles weg. Was übrig bleibt ist einfachstes HTML, dass in der Regel aus genau einem Wort bzw. Buchstaben besteht... <b> oder <li> z.B.
Ausnahmen sind dann links und Bilder. Die könnte man aber auch so reduziert und sortiert liefern, dass der Browser damit wenig Probleme bekommt.
Beispiel (Bilder) :
Aus
<img src="smiley.gif" alt="Smiley face" height="42" width="42">
würde ein
<img src="smiley.gif" alt="Smiley face"> (in genau DER Reihenfolge)
oder aus
<img src="smiley.gif" height="42" width="42">
würde ein
<img src="smiley.gif" alt="smiley">
Der Browser weiß also, was nach img kommt.

Zitat von Hexworx

Ich sehe nicht das Problem, z. B. die o. g. C64-Wiki-Seite auf dem 64er (ähnlich) darzustellen, aber nicht mit ankommendem (purem oder nur etwas gefiltertem) HTML-Code. Das wird wohl auf keinem 8-Bitter ordentlich und halbwegs erträglich schnell ablaufen/verarbeitet werden können.

Wenn ich die Zeit finde, schicke ich mal, wie der c64-Wiki Text vorher und mit Proxy aussehen könnte. (Welcher Wiki-Text? Leg mal einen link fest)

Ich lese da jetzt lange mit, benutze wohl noch länger Contiki und empfehle wieder einmal den Teletext Standard. Siehe live auf http://teletext.orf.at/ *duckundwiederweg*.

Anstelle Teletex würde ich dann doch eher BTX nehmen. Da gibts ja sogar schon ansetzte für eine Lösung. Und nen Client fürn C64 müsste es ja auch geben.
MikroPAD

Zitat von Retrofan

Wobei <tr> (Table-Row) in "meinem" Mini-HTML gar nicht vorkommt, weil Tabellen höllisch komplex werden können. ich wäre dafür, einen Tabulator-Tag zu erfinden und <td> in Tab und <tr> in <br> zu wandeln. Das nimmt eine Menge Komplexität raus. Die Darstellung wäre nicht perfekt aber das wird beim C64 auch niemand erwarten.

Stimmt, <tr> war etwas unglücklich gewählt.

Zitat von Chagizzz

Wenn ich die Zeit finde, schicke ich mal, wie der c64-Wiki Text vorher und mit Proxy aussehen könnte. (Welcher Wiki-Text? Leg mal einen link fest)

Nimm doch ruhig den "wiki/SEI" aus #341 von oben.

Zitat von Retrofan

dass der in der Lage wäre, statt Textverarbeitungs-Kommandos die von mir ausgesuchten 25 HTML-Befehle 1:1 abzubilden

Ich denke drüber nach, wie das (halbwegs einfach) zu bewerkstelligen wäre.

Zitat von Retrofan

Dann kannst du eigentlich schon wieder aufspringen.

Bin ich wohl nun quasi ja schon wieder .

Zitat von Retrofan

Es bleibt eigentlich nur die Frage, wie wir bei der Kommunikation zwischen Proxy und deinem Programm verfahren wollen. Wenn du sagst, du kannst dir nicht vorstellen, einen rudimentären HTML-Interpreter (25 verhältnismäßig simple Befehle) zu schreiben, und wir niemand anderen finden, der das ergänzend tun kann, dann müssen wir wohl auf dem Proxy das Simpel-HTML in deinen @@-Code wandeln. Aber wie gesagt, Mindestvoraussetzung ist, dass du mit deinem Code die nötigen HTML-Befehle abbilden kannst. Und dann muss Chagizzz natürlich noch mitspielen und einen 2 Konvertierprozess dranhängen.

Es ist eigentlich "nur" die Frage, wer sich die Arbeit machen will.

Ich gucke. Ich hatte mich oben leider etwas in Rage geschrieben. Bin aber längst wieder runter .

Hatte mich erstmal wieder mit meinem Progrämmchen beschäftigt. Auf den ersten Blick sieht man nicht viel, aber im Hintergrund ist einiges passiert: Kolumnenbreiten >$FF laufen nun (fast?) problemlos. Diverse kleine Bugs behoben. Senkrechter 8-px.-Druck läuft rund. Um diverse Steuerzeichen im eingelesenen Text verträglicher gemacht etc..

Ein merkwürdiger Bug ist gerade die berühmte Stecknadel im Heuhaufen:

Diese eine einzelne Zeile reißt immer rechts aus... Egal, wie ich die Breite einstelle, es ist IMMER diese Zeile (bzw. evtl. wohl ein gewisser Inhalt davon). Sowas macht einen einfach irre... . Da kann man fünf Baustellen freudig abhaken und dann kommt so ein einzelnes kleines A******** um die Ecke .

Ich werd dann mal ...

Es lag tatsächlich an EINEM blöden Buchstaben, nämlich dem 'C' von "Cybervergehen" (wie passend...). Durch einen falschen Sprung bei den lokalen Labels wurde das 'C' als Farb-TAB erkannt und die benötigten Pixel eliminiert. Das war's schon. Aber erstmal drauf kommen...

Bis diese Proxy-Sache geklärt ist, macht es aber wohl keinen Sinn, diesen Thread hier damit weiter zuzumüllen. Werde dann erstmal wieder auf "Heute so gecodet" rüberschwenken oder demnächst mal einen Extra-Thread aufmachen.

Neuester Stand aber noch: Alles läuft rund (mir erscheint es nun zumindest echt verdammt bug-frei) und das geschützte Leerzeichen ist nun auch drin (zu sehen als Einrückung am Anfang der Text-Blöcke und in der Überschrift). Das Leerzeichen wird also nicht überlesen wie das normale Leerzeichen. Und dann hab ich noch so einige Code-Teile verschoben, die an falscher Stelle waren und somit überflüssig x-mal durchlaufen wurden und auch hier-und-da was aufgeräumt.

Werd als nächstes wohl erstmal die angefangene Tabulator-Funktion zu Ende bringen. Sollte wohl nicht sooo schwierig werden, denke/hoffe ich. Oder auch erstmal den bedingten Trennstrich ('SHY'). Danach werde ich mich mal wirklich an den interaktiven Teil machen, sofern es Sinn macht. Bis die Tage .

Zitat von Retrofan

Die Scollbar-Up/Down-Buttons sollten übrigens je 16 Pixel hoch sein und haben keinen Abstand zueinander, sind insgesamt also 32 Pixel hoch

So soll das aussehen?

Aha.

EDIT: Nee, in deinem Mock-Up kleben die ja auch nicht zusammen. Ein Zeichen Abstand wär ja dann doch richtig gewesen. Meine Pfeile waren vorher aber nur 12 px. hoch und sind jetzt aber 16 px.

Zitat von Retrofan

ein normales C64-2K-Charset zu verwenden und in die ersten 16 Zeichen könnte man ja die Breitentabellen platzsparend ablegen (4 Bit Breite je Zeichen). 2 Breiten in einer Char-Pixelzeile ablegbar = 16 Breiten je Char. Das macht bei 16 Chars Platz genau 256 Breitenangaben, die wir benötigen. Und der Font bliebe 2K groß.

Witzige und klasse Idee. Wäre nur die Frage, ob man die dann dort auch belässt oder doch besser entpackt. Meistens hat man aber ja eh nur mit den Zeichen <128 zu tun, die man dann fortlaufend ins untere Nibble legen könnte. Das einzelne AND, was man dann nur bräuchte, dürfte gar nicht viel ausmachen. Ich teste das mal. 256 freie Bytes sind natürlich immer schön.

Zitat von Goldrider

Sind immer Lustig die Leute mit ihren MockUps für völlig unrealistische Projekte.

Du hättest auch einfach weiter gehen und den Spruch für dich behalten können. Wär ich Mod, hättest du jetzt Frischluft.

Gegenfrage: Wann kannst DU denn so?

Welche Mock-Ups du jetzt auch meintest: Was Retrofan grafisch schon auf die Beine gestellt hat, steht wohl außer Frage und so manches (auch von anderen) hatte nur mal ein Mock-Up als Anfang.

Also nächstes Mal bitte einfach kopfschüttelnd im Forum weiter ziehen. Danke.

Zitat von Retrofan

Nein. Sondern so

Ja, war ein Denkfehler bei mir. War weiter oben bis auf das Leerzeichen also doch schon richtig.

Die Zeichen-Breiten habe ich eben schon mal testweise in Nibbles gewandelt. Mal schauen, was dabei rauskommt. Gute Nacht.

Zitat von Goldrider

Ich spreche dem Retrofan ja nicht sein grafisches Talent ab. Ich kenne nur solche Leute mit tollen Ideen und ein paar Skizzen und die wundern sich dann warum man das nicht realisieren kann.

In gewissen Spieleprogrammierer-Foren gibt es zugegeben wirklich oftmals wahnwitzige Ideen. Ist aber hiermit eher nicht vergleichbar, denke ich.

Zitat von Goldrider

Ich gehe jeder Wette ein, wenn ich nächstes Jahr hier noch einmal rein schaue, so werde ich nicht wirklich mit dem C64 vernünftig surfen können. Proxygefrickel hin oder her, das wird nix.

Ich kann nicht dagegen wetten, da ich die Proxy-Geschichte mangels Ahnung nicht stemmen können werde. Aber kein Grund, das Projekt mit "Gefrickel" und "das wird nix" negativ runter zu ziehen. Vielleicht kannst du aber ja was zum Gelingen beitragen?

Zitat von Goldrider

Ich habe hier in dem Forum schon tolle Projekte gesehen, aber das hier ist wirklich

Scheiße, weil: ...?

Zitat von Goldrider

Wegen einer Meinung soll mich ein Moderator sperren?

Das waren eben keine Meinungsbekundungen (geht nicht, weil...), sondern nur negatives Gebashe von dir.

Zitat von Goldrider

Vom ewigen Baupinseln hat keiner was.

Sie meinten: "Bauchpinseln"? Nö, tut auch nicht Not. Geht so oder so weiter.

Lass uns mal machen, wenn wir das lustig finden und damit unsere Freizeit verbrennen mögen. Mir macht's jedenfalls gehörig Spass .