Posts by mgroeber

    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:

    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.

    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.

    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?

    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.

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

    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.

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

    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.

    Übrigens: ich habe unter https://mgroeber9110.github.io/just-the-docs-test/ eine Testversion für Verbesserungen an der Dokumentation aufgesetzt. Im Moment sieht es noch ziemlich ähnlich aus, verwendet intern aber schon die aktuellen Versionen von jekyll und just-the-docs für die Konvertierung. Mein Plan ist, da erst mal Verbesserungen zu testen und dann in wenigen PRs zu sammeln.

    Der Inhalt ist evtl. veraltet, weil ich einen früheren Schnappschuss der Markdown-Files verwende - es geht hier nur um das Format der Webseite, Suchfunktion usw. Ein paar Sachen, die mir aufgefallen sind und die ich mir gerade ansehe:

    • Das Laden großer Seiten friert bei mir für eine Sekunden ein, wenn man zu schnell scrollt, weil im Hintergrund erst mal die Suchfunktion den Index aufbaut. Leider passiert das bei jeder Seite neu. Dafür habe ich auch schon ein Issue bei just-the-docs geschrieben: https://github.com/just-the-docs/just-the-docs/issues/1396
    • Suche nach Stichworten führt immer zum Anfang des Dokuments, anstatt zur Zwischenüberschrift des Kapitels mit dem Begriff.
    • Sortierreihenfolge in der Übersicht stimmt nicht für alle Kapitel, weil lexikalisch und nicht numerisch sortiert wird (1, 10, 11, 2).

    Ich sehe das auch so, dass auf die Dauer nur eine Version der Doku "von Hand" gepflegt werden sollte (vermutlich am besten Markdown), und die HTML-Doku dann regelmäßig automatisch daraus erzeugt wird. Bevor wir sie überschreiben, sollten wir aber vielleicht noch mal vergleichen, was drinsteht. Dass man die HTML-Variante sogar direkt in Geos lesen kann, ist natürlich ein Argument dafür, das Format beizubehalten (mit minimalem CSS).

    Die Text-Version ist m.E. vermutlich auf Dauer ganz obsolet (weil MD ja sogar im Editor fast so gut lesbar ist wie plain text, bis auf ein paar Sonderzeichen) - wenn wir auch sicher sein können, dass es dort nicht noch Infos gibt, die wir nicht in Markdown haben.

    Ich habe jetzt erst mal ein Issue bei just-the-docs geschrieben, da der Fehler wohl auch in der aktuellen 0.10 noch drin ist: https://github.com/just-the-docs/just-the-docs/issues/1634 - mal sehen, was die schreiben, oder ob da vielleicht sogar eine Idee dahinter steckt (h4 wird in Großbuchstaben umgewandelt, daher könnte jemand eine etwas kleine Schrift durchaus für typographisch sinnvoll gehalten haben...). Ich find's aber auch zu klein.