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

  • Ich dachte, dass wir den sowieso schon haben, um die übersetzten (deutschen) Resourcen in die compilierten .geo-Files zu integrieren.

    Doch, das ist richtig, den Part macht ResEdit im Batchmodus. Nur ist die Liste m.W. nicht mit ResEdit übersetzbar.

    Nur so als Idee: Evtl. könnte man nach dem Übersetzen das übersetzte Target starten, dort Preferences die (deutsche) Liste bauen lassen und die dann irgendwie benutzen ???

    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

  • Eher Preferences bei Autostart eintragen und ihm per speziellem INI-Eintrag sagen, das es GEOS runterfahren soll, wenn es mit dem Bauen der Liste fertig ist.

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

  • Die Liste wurde bei mir aber nicht sofort komplett gebaut, sondern erst nach Aufruf z.B. von 'Drucker'. Nach Aufruf der Voreinstellungen war die Datei nur 3KB groß. Nach Aufruf von Drucker war Sie 47KB groß. Die im Repo ist 45KB.

    Kann das jemand bestätigen?

  • Stimmt, viele Module ergänzen die Liste. Unter dem EC-target war sie anfangs 3.784 Byte große, Nach dem aufruf dieverserr Module (Background, Mouse, Keyboard, Video ... ) war sie mit Zwischenschritten letztlich über 86 kB groß

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

  • Hi,
    ja, wir haben schon jetzt PC/GEOS im Build-Prozess wenn es an den Übersetzungsschritt geht, da könnte man also ansetzen.

    Mit den Preferences-Icons ist es noch etwas komplizierter. Preferences verwendet die Icons für die Listendarstellung aus der Token-DB. Dort liegt die Icon- und Text-Representation. Die Token-DB wir befüllt, wenn ein neues Preferences-Modul registriert (das erste mal angezeigt) wird, das ist der Fall, wenn man die Device-Liste löscht, oder wenn das Icon gebraucht wird und nicht in der Token-DB gefunden wird. Man kann also auch die Token-DB löschen um die Icons für die Preferences-Liste zu aktualisieren. Da spart man die Zeit um die Device-Liste neu aufzubauen. Da er auch die Text-Representation mit in die Token-DB schreibt, wird diese dann Lokalisierungsabhängig. Man müßte also nach einer Übersetzung sowohl die Device-List als auch die Token-Db neu generieren lassen.

    Viele Grüße,
    Falk \\ blueway.Softworks

  • Irgendwie scheinen die "alten" Icons in de Token-DB zu sein und Perferences ersetzt sie dann? Aber nur, wenn es keine Device-Driver_List gibt (oder das Icon nicht in der TokenDB ist)? Dann würde es doch reichen, die Pref-Icons aus der Token-DB zu entfernen?

    Rainer

    P.S. ich habe den Eindruck, dass in der mitgelieferten Token-DB die deutschen Text (Hintergrund satt Background) sind. Das EC-Target hat im Normalfall keine (EC) Device driver list. Um ihn zu überreden, die Icons nicht upzudaten habe ich die Liste gesicheert, das target neu gebaut und die Liste wieder eingespielt. Das ist das Ergebnis:

    Nach dem Löschen der Liste sieht es dann so aus.

    Mein Fazit: Das Mitliefern einer DeviceDriverList macht nur Ärger :)

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

  • N' Abend.

    Ich habe zwar nix neu gebaut, aber nach dem Löschen der Device Driver List und einem Neustart hatte ich das von Rainer gezeigt Bild. Wie man sowas automatisiert... :/

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

  • Ja, die Token-DB enthält aktuell die alten deutschen Icons. Das sollten wir auch korrigieren.

    Module werden in der "Device driver list" aktualisiert, dabei auch die TokenDB aktuallisiert, wenn deren Version sich in einen der ersten 3 Stellen geändert hat. Im englischen Release ist eine originale "Device driver list" vermutlich mit 4.x.y-Versionen der Preferences-Modules. Darum werden die Icons in der englischen Version beim Start übernommen. Im deutschen Release ist eine deutsche Version der "Device-driver-list" die schon auf V6.0.0-Modulen initialisiert ist, darum werden die Icons dort nicht aktualisiert.

    Ich bereite gerade einen Update (PR) vor, der für alle Module mir neuen Icons die Version auf 6.0.1 setzt. Dann sollte das Update funktionieren.

    Viele Grüße,
    Falk \\ blueway.Softworks

  • Nee, biste nicht, aber ich denke die Abstimmung war nur auf Discord. Das ist doof, für die, die nicht dort mit aktiv sind. Wir sollten uns vielleicht angewöhnen, für Abstimmungen ein externes Tool zu nutzen und das dann hier und auf Discord zu verlinken...

    Mütze Es gab auf Discord eine Abstimmung zu dem Thema. Die Idee war hier, wieder ein bisschen zu den Wurzen zurückzukehren - GEOS 2 hatte dieses Layout bei den Prefs. Ein Vorteil ist, dass man auch bei nicht funktionierender Maus relativ gut durch alle Module gehen kann um Einstellungen vorzunehmen, ohne Scrollen zu müssen... Aber ich gebe zu, es ist etwas gewöhnungsbedürftig :)

    Bye,
    MeyerK

  • Ich hatte schon befürchtet, dass es keine versehentliche Änderung ist. Und halte einfach nochmal dagegen: ;)

    1. Einige Design-Entscheidungen wurden damals natürlich auch aufgrund der damals viel kleineren Bildschirme getroffen. Darum waren u.a. die Fileselector-Fenster so klein, das Voreinstellungen-Fenster so klein, das Kalender-Fenster so klein, die Zeichensatztabelle so klein, usw...

    2. Wie es aussieht, muss man bei der neuen Anordnung ebenfalls scrollen - nur eben etwas weniger.

    3. Meiner Erfahrung nach ist eine nicht erkannte / nicht vorhandene Maus, oder dass jemand GEOS grundsätzlich ohne Maus verwenden möchte, eher die Ausnahme.

  • Ich hatte schon befürchtet, dass es keine versehentliche Änderung ist. Und halte einfach nochmal dagegen: ;)

    1. Einige Design-Entscheidungen wurden damals natürlich auch aufgrund der damals viel kleineren Bildschirme getroffen. Darum waren u.a. die Fileselector-Fenster so klein, das Voreinstellungen-Fenster so klein, das Kalender-Fenster so klein, die Zeichensatztabelle so klein, usw...

    Das stimmt! Eigentlich sollte sowas bildschirmgrößenabhängig sein und GEOS unterstützt das sogar. Allerdings nicht bei den Prefs, da ist es n "aus Gründen" hard-codiert, wenn ich das richtig gesehen habe.

    2. Wie es aussieht, muss man bei der neuen Anordnung ebenfalls scrollen - nur eben etwas weniger.

    Leider ja, finde ich auch etwas doof.

    3. Meiner Erfahrung nach ist eine nicht erkannte / nicht vorhandene Maus, oder dass jemand GEOS grundsätzlich ohne Maus verwenden möchte, eher die Ausnahme.

    Das stimmt natürlich. Allerdings habe ich es mehr als einmal erlebt, dass GEOS mit nicht funktionierender Maus hochkam, aus welchen Gründen auch immer. Dann war es nervig zur richtigen Stelle zu navigiere. Zum Beispiel ist unser momentanes out-of-the-box Erlebnis ja auf Basebox/Dosbox ausgerichtet, deswegen ist die Maus unter FreeDOS erst mal nicht funktional. Das wird man sicher ändern, mit 6.1ff...

    Bye,
    MeyerK

  • Moin.

    Was die "neuen" Voreinstellungen angeht bin ich auch der Meinung, das hier die Module oder Kacheln zu klein und damit zu eng angeordnet sind; die Modulnamen sind zum Teil nicht mehr kokplett zu lesen und es ist auch nicht mehr so übersichtlich. Ich bin für die alte Version, zumal das Argument der kleinen Monitore heutzutage wohl nicht mehr ins Gewicht fällt.

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!