Posts by mgroeber

  • WebMagick

    Quote from sebi

    Braucht man für CSS auch einen DOM? Vielleicht für Angaben wie „alle Kindelemente von …“. Aber es gibt auch ja Angaben wie wie „alle Links“ oder „p-Elemente“. Wenn man das vorher einliest … aber die Teufel werden schon in den Details hausen.

    Ich würde sagen, es gibt für CSS in WebMagick drei Stufen:

    1. Inline-Style-Attribute parsen. Dafür gibt es sogar schon eine Funktion, die man "nur noch" ausfüllen müsste, um ein style-Attribut in die WebMagick-interne Style-Struktur zu übersetzen. Das ist für Properties wie font-size vermutlich relativ einfach, aber es dürfte nicht oft benutzt werden, weil fast alle Webseiten Stylesheets und Klassen/IDs verwenden.
    2. Stylesheets parsen und und Selektoren richtig anwenden (z.B. "div der Klasse big-title" oder eben "alle Links"), um für jedes Element die entsprechenden Style-Attribute der passenden Regeln zusammenzusuchen. Etwas mehr Aufwand, aber wohl auch weitesgehend mechanisch, weil man "nur" die CSS-Regeln in entsprechende kompakte Datenstrukturen übersetzen und dann schnell durchsuchen muss...
    3. CSS richtig layouten: das ist wohl die Königsdisziplin, weil es letzten Endes das Tabellelayout komplett ersetzen und die ganze Geometrie einschließlich Textumbruch berechnen müsste. Das ist ein Schwierigkeitsgrad, den sogar nur wenige große Browser-Teams fehlerfrei geschafft haben, und bei dem ich nicht sicher bin, ob es lohnende Zwischenschritte gibt (z.B. nur bestimmte Modelle wie etwa Grid-Layouts zu unterstützen, die man vielleicht sogar auf unsere Tabellen-Engine zurückführen könnte).

    Auch dieser Zustand würde vermutlich noch zu sehr vielen Layoutfehlern führen, weil sich wohl fast alle Seiten zusätzlich auf DOM+Javascript verlassen, um dynamisch einzelne Teile (z.B. Menüs) ein- und auszublenden. Außerdem dürften viele Seiten mit einer Menge Trial-and-Error geschrieben sein, wo eben so lange mit Attributen gespielt wurde, bis es in gängen Browsern (d.h. Chrome, Chrome und Chrome) halbwegs richtig aussieht.

    Deshalb würde ich die ersten beiden Schritte für realistisch halten (Schritt 1 auf jeden Fall), während man sich für den dritten vermutlich ein Jahr Urlaub nehmen sollte - wahrscheinlich würde dazwischen sogar noch ein Prototyp stehen, der z.B. die Umwandlung von CSS-Grids in Tabellen erst mal in Python durchspielt, damit man das an realen Seiten testen kann (wenn man Schritt 2 und 3 auf einem Proxy machen würde, der Webseiten dynamisch umschreibt, wäre es sogar etwas, das noch anderen Legacy-Browsern helfen könnte).

  • WebMagick

    Der Effekt geht sogar noch etwas weiter und betrifft alle Zeichen-Stile: wenn ich Firefox und WebMagick vergleiche, scheint das "korrekte" Verhalten zu sein, die Aufzählungszeichen im Stil des <ul>-Elements zu formatieren, während WebMagick den Stil des ersten Zeichens des Elements kopiert.

    Zum Vergleich (links FF, rechts WM) - die Absatzabstände sind auch noch mal eine interessante Sache:

    HTML:

  • Kleines JPG-Problem?

    Vielleicht ist es eine falsche Vorrangbehandlung zwischen den Einträgen: wird bei der Zuordnung per Datei-Extension der letzte Eintrag genommen, gewinnt "jpg -> image/jpg", und dann ist der Mime-Typ falsch.

    Im Prinzip ist ein Mapping "image/jpg -> imp library" nicht schlecht, falls der Mime-Typ auf einem Server falsch konfiguriert ist, aber dieser Typ sollte dann nicht für lokale Dateien benutzt werden.

    Es könnte also sein, dass es geht, wenn man einfach nur die Reihenfolge der beiden JPG-Zeilen tauscht.

    WAV weiter unten macht übrigens etwas ähnliches.

  • MSG_GO_ROTATE im alten und neuen SDK

    Quote from Wilfried

    Muss dringend geändert werden: Im aktuellen Repository (grobj.goh) steht noch immer:

    @message void MSG_GO_ROTATE( /* XXX */
    GrObjHandleSpecification center = bp,
    WWFixedAsDWord angle = dx.cx);

    Das Rotieren funktioniert aber nur mit angle = cx.dx.

    Ich habe jetzt mal eine PR dafür gemacht: https://github.com/bluewaysw/pcgeos/pull/1003 - damit wird auch die alte Reihenfolge wiederhergestellt, weil es eigentlich keinen Grund gab, sie zu ändern, außer der Sache mit WWFixedAsDWord.

    Dabei habe ich auch noch versucht, die Doku für WWFixedAsDWord etwas zu verbessern, weil dort offenbar mal der Typ geändert wurde, ohne dass das je angepasst worden ist.

  • Repräsentativer Screenshot von FreeGEOS?

    Mir ist neulich aufgefallen, dass die Titelseite der SDK-Doku (https://bluewaysw.github.io/pcgeos/) und vermutlich auch das Readme in github (unten auf https://github.com/bluewaysw/pcgeos) davon profitieren würden, wenn wir gleich einen schönen Screenshot (640x480 oder 800x800) zeigen könnten, der dem uneingeweihten Besucher sofort klar macht, dass es hier um eine graphische Oberfläche geht.

    Hat jemand einen Vorschlag, den wir dafür nehmen könnten?

  • MSG_GO_ROTATE im alten und neuen SDK

    Quote from Wilfried

    Aber ich wüsste gar nicht, wie und wo ich Zugang zu den MD-Texten bekomme.

    Zumindest das ist recht einfach zu erklären. :)

    1. Online-Dokumentation hier öffnen: https://bluewaysw.github.io/pcgeos/
    2. Irgendwie (z.B. im Suchfeld) zur Seite mit MSG_GO_ROTATE navigieren: https://bluewaysw.github.io/pcgeos/Objects…l#msg_go_rotate
    3. Ganz unten auf der Seite steht ein Link: Edit this page on GitHub
    4. Der führt dann zum Quelltext der Seite im Repo: https://github.com/bluewaysw/pcge…jects/ogrobj.md (zuerst wird die formatierte Version angezeigt, und unter "Code" gibt es dann den Markdown-Text, wie er im Repo steht)
    5. Hier wäre dann die Stelle zum Editieren: https://github.com/bluewaysw/pcge…d?plain=1#L2303

    Ich glaube, man kann die Datei sogar gleich auf der Webseite von GitHub ändern und einen PR machen, aber das habe ich noch nie probiert. Ich würde das dann einfach mit dem PR machen, der auch die Include-Datei korrigiert.

    Sobald der PR gemerged ist, wird die Webseite automatisch neu erzeugt.

  • MSG_GO_ROTATE im alten und neuen SDK

    Quote from Rainer

    Btw: Wer pflegt dass abschließend in die Dokumentation ein? Aktuell steht da
    MSG_GO_ROTATE

    Code
    void    MSG_GO_ROTATE (
        WWFixed                     angle,
        GrObjHandleSpecification    center);

    This message rotates the GrObj about one of its handles.

    Vielleicht wäre es am einfachsten, wenn Wilfried das mit der getesten Änderung der Signatur macht, dann passt gleich alles zusammen - es reicht ja, die Änderung nur in den Markdown-Techdocs zu machen, der Rest dürfte über kurz oder lang sowieso verschwinden (ASCII enthält eigentlich schon nichts mehr, was wir nicht auch in Markdown haben, während HTML noch einige Communicator-APIs wie etwa die foam-Library bewahrt, die allerdings im Sourcecode nicht vorhanden sind).

  • MSG_GO_ROTATE im alten und neuen SDK

    Das Problem war, dass einige Prototypen for Messages in GOC im alten SDK falsch waren, so dass ich mir im Laufe der Zeit ein Headerfile "fixes.goh" mit korrigierten Prototypen geschrieben habe. Meist betraf das Messages mit einem "XXX"-Kommentar von Geoworks (bin mir nicht sicher, ob das vielleicht "ungetestet" bedeutet, oder "noch ungelöste Probleme"?).

    Irgendwann letztes Jahr habe ich diese Änderungen dann mal zurück übertragen und fixes.goh entfernt, damit die "offiziellen" Header korrekt sind. Vermutlich habe ich dabei in dieser Message versehentlich die Register-Definition falsch herum abgeschrieben, während eigentlich nur die richtige Reihenfolge der Parameter nötig gewesen wäre. Eigentlich dachte ich, dass V-Convert diese Funktion auch nutzt und mir das beim Portierern hätte auffallen müssen, aber evtl. habe ich keine Testdatei verwendet, die eine Drehung enthielt...

    Wenn es so herum klappt, würde ich den Fix einfach einchecken. Danke für's Finden! :)

    ps: Es kann sein, dass auch noch irgendein Problem mit der Übergabe von Strukturen als Parameter auf dem Stack aufgetreten ist, daher vermutlich der Wechsel zu WWFixedAsDWord, weil das besser zwischen Compilern portabel sein sollte.

  • Kleines GIF-Problem?

    Ich hätte den Verdacht, dass der Browser (warum auch immer) in eine 256-Farben Bitmap mit Systempalette schreibt und darum die RGB-Farben ohne Dithering immer auf die nächstliegende Systemfarbe mappt. Immerhin trifft er ja grob die Farbe...

  • GEOS Doku nicht mehr auf Github.io?

    Ich hab mal ein bisschen die beiden anderen Formate (ASCII, HTML) mit Markdown verglichen, um den aktuellen Status zu haben und zumindest einen theoretischen Plan zu formulieren:

    • ASCII ist vermutlich die Grundlage, die John Howard verwendet hat, um die Markdown-Version zu erstellen:
      • Aufteilung in Dateien und Zeilenumbrüche sind (stichprobenweise) identisch, nur eben mit Markdown-Formatierung, Inline-Grafiken, Links statt Seitennummern usw. formatiert. Das muss eine Heidenarbeit gewesen sein...
      • Es ist noch ein Zoomer-spezifisches Kapitel enthalten, das noch kein Markdown-Gegenstück hat.
      • Außerdem gäbe es noch ein paar kleine Abschnitte von "historischem" Interesse, z.B. Credits (Namen der Doku-Autoren und beteiligen Entwickler) und Copyrights. Evtl. sind die es wert, erhalten zu bleiben.
    • HTML hat viele technische Übereinstimmungen, ist aber anders organisiert und enthält vor allem Communicator-spezifische Ergänzungen
      • Effektiv ist das die Dokumentation des Nokia 9000-SDKs, vermutlich stellenweise überarbeitet (1994 bis 1997)
      • Viele Abschnitte sind identisch mit dem Text der Markdown-Dokumentation - es gibt jeweils ein "combo.htm"-File, das alle HTML-Files eines Verzeichnisses zusammenfasst und das oft z.B. einem Oberkapitel in "Concepts" entspricht.
      • Nokia 9000-spezifiche Ergänzungen sind teilweise als getrennte Sektionen eingefügt (z.B. alles unter "Nokia9000", als auch alphabetisch in die Referenzen einsortiert (z.B. API-Routinen für Access Points und "Foam", also die Nokia-spezifischen APIs)

    Meine Einschätzung wäre daher: ASCII kann fast komplett weg, wenn man Zoomer-Teil und die Credits vorher noch irgendwo unter Markdown unterbringt, damit die Info nicht verlorengeht.

    HTML aus dem Nokia 9000 benötigt etwas sorgfältigere "Textarbeit", wenn man es retten will: erst mal die combo-Files so sortieren, dass die Struktur der Markdown-Doku entspricht, dann HTML>Markdown-Konverter, und dann die Unterschiede in Markdown einpflegen: die komplett plattform-spezifischen Abschnitte ziemlich en-bloc, und dann irgendwie (mit KI-Hilfe?) einen intelligenten Abgleich der überlappenden Teile machen.

    Der letzte Punkt dürfte dabei der aufwendigste sein, je nachdem, wie viele Korrekturen Geoworks bis zum Erscheinen des Nokia 9000-SDKs in die HTML-Version eingebaut hat und an wie vielen Stellen man einzelne Routinen, Structs usw. einsortieren müsste.