Posts by mgroeber

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

  • DWFixed in der HTML-Doku falsch

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

  • DWFixed in der HTML-Doku falsch

    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.

  • Formatierung Titelgrösse der FreeGEOS Techdocs auf github.io

    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.

  • WebMagick

    Das Problem mit den Unterstrichen ist vermutlich eine Regression von diesem Fix: https://github.com/bluewaysw/pcgeos/pull/756

    Da hatte ich die HTML-Aufzählungen so geändert, dass die Zahl (oder der Punkt) genau die gleichen Zeichenattribute verwendet wie der Rest des Eintrags. Das ist vermutlich bei Farben, Fettdruck, Schriftart auch ganz sinnvoll, aber vermutlich sollte man Unterstreichungen da abschalten. wenn es andere Browser auch so machen.

  • PS to PDF conversion in Geos and DOS

    Quote from MeyerK

    Ich habe neulich mal in den Source geguckt und festgestellt dass die über große Strecken "malloc" genutzt haben, die Speicherverwaltung ist nur so halbherzig auf GEOS angpeasst. Da wäre also noch Luft nach oben....

    Ein Kandidat wäre https://github.com/bluewaysw/pcgeos/issues/757 - die Inflate-komprimierten Streams (Zip-Kompression) stattdessen per zlib zu implementieren, wo du ja schon ein paar Verbesserungen an der Speicherverwaltung gemacht hast. Es gibt natürlich noch eine Menge anderer mallox-Sachen (z.B. ein großes Array von Font -Informationen, wenn ich mich richtig erinnere), aber eine einheitliche Library für das Auspacken wäre schon mal was.

  • Idee: lokale Homepage für den Browser?

    Mal so ein Gedanke: wie wäre es, wenn wir im Standard-Paket von Ensemble nicht die Blueway-Seite direkt als Homepage einstellen, sondern stattdessen auf eine lokale Datei verweisen, die dann Links zu Blueway, Infobase und vielleicht ein paar anderen Seiten liefert, die gut mit dem Browser funktionieren?

    Außerdem könnte die Seite vielleicht ein paar Browser-Features unaufdringlich demonstrieren, z.B. eine Grafik laden und ein Tabellenlayout mit verschiedenen Schriften, Aufzählungen usw.

    Damit hätte ein Nutzer auch ein kleines Erfolgserlebnis, wenn die Verbindung zum Internet noch nicht hergestellt ist.

    Die Seite müsste natürlich auch übersetzt werden.

    ciao marcus

  • Browser UI Project

    Quote from Achim

    Aber zunächst sollte die Programmoberfläche vernünftig eingedeutscht werden.

    Da wäre die interessante Frage, wie viel da überhaupt an der deutschen Übersetzung geändert werden muss, und wie weit ResEdit die Objekte immer noch findet, so lange sie ihre Namen behalten haben - ich vermute, die meisten Texte dürften ja ziemlich ähnlich sein, und nur die Verteilung auf die Resourcen ist vielleicht etwas anders geworden. So wie ich mich dunkel erinnere, müsste ResEdit da eigentlich relativ robust sein.

    Soweit ich das auf die Schnelle bei https://mgroeber.de/geos-live_d.html sehe, sind die meisten Übersetzungen wohl schon vorhanden, bis auf das Optionen-Menü, sowie eigenartigerweise der Titel des "Page Setup"-Dialogs und "HTML > Save Source Code".

  • CI-Latest

    Quote from t.hass

    Die Datei gehört nicht ins Build, weil sie bei jeder Änderung von Strings im Code neu erzeugt werden muß, damit alles richtig funktioniert. Das würde implizit einen GEOS-Boot im Buildprozeß erfordern.

    Ich dachte, dass wir den sowieso schon haben, um die übersetzten (deutschen) Resourcen in die compilierten .geo-Files zu integrieren. Oder habe ich das falsch in Erinnerung, und das geht auch mit der Kommandozeile unter Windows/Linux?

    Im Prinzip wäre ein Build-Prozess, der GEOS nutzen kann, natürlich eine feine Sache, weil wir damit die Möglichkeit hätten, komplexe plattformspezifische Dateiformate viel leichter dynamisch zu erzeugen (sagen wir mal, übersetzte Hilfedateien aus einem textbasierten Quellformat, das sich viel leichter in git verwalten ließe als die aktuellen Binärdateien).