Eigene WinVICE-Änderungen

Quote from markusC64

Ich habe mir Deine eingecheckten Branches heute mal angesehen: Ich bin begeistert. Die SID-Backports ergänzen sich mit meinen SID-Backports gegenseitig. So wird das bestimtm ein Genuss für die Ohren.

Danke, das tut gut zu hören.

Im Hintergrund informiere ich mich in der mir zur Verfügung stehenden Freizeit gerade leider so viel über für Änderungen benötigte Grundlagen, dass ich mit meinem Code-Output (quantitativ) noch nicht zufrieden bin. Was ich mir gerade nebenbei in der Freizeit aneigne:

• Win32API, um native Dialoge, Menüs etc. nicht nur im trial & error bearbeiten zu können (erster sehr wichtiger Schritt ist die About-Box, um trotz eigener Versionsinformationen Credits für die Originalversion vom VICE-Team geben zu können)
• Autotools (habe mir das Buch "Autotools, 2nd Edition: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool" von John Calcote gekauft), um auch bei Anpassungen des Build-Systems mehr als trial & error machen zu können
• Git über Basiswissen hinaus (ich konnte wie die meisten mit Git umgehen, aber wie es denn wirklich funktioniert und welche Ansätze in dieser besonderen Umgebung und Problemstellung welche Vor- und Nachteile haben, so tief steckte ich bisher nicht drin); ich mache alles per Kommandozeile, um es wirklich zu verstehen und die volle Kontrolle darüber zu haben.
• Innerer Aufbau von VICE. Klingt für bereits beteiligte Entwickler vielleicht lächerlich trivial, aber wie die Kette der Aufrufe und verschiedene Gegebenheiten realisiert sind, muss ich nun einmal für weitere Änderungen wissen. Beispiel: Ich möchte meinen Quick-Fix per Option schaltbar machen. Dafür brauche ich Änderungen am nativen UI (Win32API, siehe oben), muss die Option in den Einstellungen speichern, muss sie dann an den entsprechenden Stellen wirksam werden lassen und ggf. den Build ergänzen (im Falle neuer Dateien). Ebenso die Informationen für die Quick-Fix-Berechnung durch die Kette durchzureichen (Parameter vs. #DEFINE vs. ...).

Naja, ich kämpfe mich weiter durch...

Quote from markusC64

Die Speedanzeige habe ich in meiner internen Testbuild erst mal dirngelassen - im Moment habe ich das Gefühl, es wäre gut, wenn man Toolchains damit vergleichen könnte, was die leisten. Zum Bsp. durch Vergleich, was in Warpmodus an Geschwindigkeit rauskommt.

Guter Punkt. Ich hatte eben mal geschaut, ob ich die relativ einfach nur im Warp-Modus aktivieren kann. Aktivieren ist kein Problem, allerdings das anschließende Deaktivieren. Dort müsste ich den Titel zurücksetzen, aber die Implementierung lässt dies ohne Refactoring nicht zu. Der Titel wird nämlich direkt in den ui_display_speed-Methoden (ui.c) gesetzt, statt dass diese eine set_title-Methode aufrufen, die ich zum Löschen verwenden könnte. Und diese Methoden sind arch-spezifisch (müsste dann also alle umbauen); dies wäre ja noch machbar, jedoch hätte ich dann heftige Mergekonflikte wenn ich aus vanilla-vice sukzessive Weiterentwicklungen weiter reinmerge. Und genau die Geschwindigkeitsanzeige hat sich ja (zumindest bei GTK3) scheinbar von 3.2 zu 3.4 von Titelzeile zu Statusbar bewegt. Da macht es mehr Sinn, wenn ich die auch in der nativen Oberfläche in die Statusbar verschiebe (und ggf. erstmal nur im Warp aktiviere, bis die auch im nicht-Warp stabil ist, sofern die angezeigte Emulation selbst stabil ist).

Quote from markusC64

PS: Ich sehe gerade: Im konvertierten git (aus dem svn) gibt es jede Menge Branches "viceplus/<versionskennung>" - vielleicht ist "WINVICE+" demnach als Name doch verwechslungsgefährdeter als gedacht.

Ist nun leider zu spät, sonst fange ich mit dem Repo wieder von vorne an, außerdem hatte ich lange mit AW182 über Namen philosophiert und auf wirklich bessere sind wir nicht gekommen. WinVICE soll ja gerade für die native Oberfläche stehen wie sie früher vorhanden war und es sie nicht mehr gibt; das "+" für Ergänzungen ggü. auch aktuellen vanilla-VICE-Versionen. Außerdem soll es auch die Arbeit des offiziellen VICE-Teams würdigen, statt dass ich etwas unter komplett anderem Namen laufen lasse wo der User keine Rückschlüsse mehr auf das Projekt zieht, welches die fantastische Leistung eines so guten Emulators hervorgebracht hat.

Allerdings sehe ich auch nicht wirklich ein Problem: Ich nutze keine zusätzlichen Branches vom vanilla-VICE. Ich nehme nur den Code als Basis, der im "trunk" ist. Bei dir sind sie (zumindest im öffentlichen Bitbucket) auch nicht vorhanden. Da ist eigentlich eine gute Entkopplung vorhanden. Egal welchen Namen ich wählen würde, theoretisch könnte den auch jemand im Subversion als Branch-Namen vergeben. Irgendwo muss man eine Entkopplung machen, und bei mir ist die genau dort.

Quote from markusC64

Ist auch nicht schlimm... Dann muss das Versionsschema eben den offensichtlichen Unterschied hergeben. Jahr.Monat.Nr - die Nummer am Ende auf 0, es sei denn, in dem Monat sind mehrere Releases nötig, wäre eine Idee.

Genau, das war einer der Gründe, warum die aktuelle Version "pre-2020.1" ist, um zum Einen keine Möglichkeit der Verwirrung mit 3.4 etc. zu bieten, zum Anderen mag ich irgendwie eine datumsbezogene Version. Genau deinen Vorschlag hatte ich auch überlegt, aber da würde man die Nummer mit dem Tag verwechseln. Derzeit dürfte ich nur eine Releaseversion im Monat machen

Wenn ich bspw. in diesem Monat ein Release schaffe, wäre "pre-2020.2" die nächste Entwicklungsversion. Auch wenn ich übliche Versionierungsschemas durchaus kenne, finde ich es unlogisch, wenn die Version erst mit einer neueren Nummer beginnt, und danach "rückwärts" durch alpha, beta, RC etc. eingeschränkt wird. Eigentlich möchte ich direkt am Anfang sehen, dass es sich noch nicht um die danach folgende Version handelt, deshalb das "pre-".

Damit ich nicht zu viele Mergekonflikte bekomme, werde ich wohl erst einmal nicht direkt an der Version drehen, die durch das bestehende Buildsystem geht. Da müsste ich auch die Berechnung der "einzahligen" Versionsnummer ran, die derzeit je nach Position der Zahl multipliziert und dieses aufaddiert. Bei 2020 als Majorversion käme eine irre einzahlige Versionsnummer raus.

Quote from angryking

Wobei ein versierter Programmierer da wohl schlauer zu Werke geht als ich mit Notepad++

Ich bin derzeit Fan von Visual Studio Code. Ist mein Standardeditor geworden, ge-build-et wird in diesem Fall direkt in der MinGW/MSYS2-Konsole. Für Git die Git Bash. Mache dies ja unter Windows, da kann ich auch mehrere Windows nutzen.

Ggf. probiere ich mal interessehalber aus, ob ich das ins Visual Studio 2019 kriege. Bzgl. Buildsystem wäre es eher der Horror, könnte aber punktuell für die UI-Entwicklung interessant sein. Ansonsten geht das wie oben geschrieben schon sehr angenehm über die Bühne...

Quote from markusC64

Die Speedanzeige habe ich in meiner internen Testbuild erst mal dirngelassen - im Moment habe ich das Gefühl, es wäre gut, wenn man Toolchains damit vergleichen könnte, was die leisten. Zum Bsp. durch Vergleich, was in Warpmodus an Geschwindigkeit rauskommt.

Nach einem Revert des pauschalen Ausblendens habe ich es nun folgendermaßen für die Windows-Version gelöst:

1. Geschwindigkeitsanzeige in die Statuszeile verschoben
2. Temporäre Anzeigen wie "Attached xyz.d64 to device#8" in der Statuszeile übersteuern die Anzeige der Geschwindigkeit
3. Workaround: Geschwindigkeitsanzeige nur im Warp-Mode, um Benchmarks zu ermöglichen; sobald die Geschwindigkeitsanzeige bei absolut ruckelfreier Anzeige konstante Zahlen anzeigt, werde ich sie ggf. generell wieder aktivieren

Separate Commits: Revert, Kombination aus 1&2, Workaround aus 3.

Quote from angryking

Was übrigens im WinVICE GUI offenbar immer gefehlt hat, sind die Einstellungen für den Monitor.

Tatsache, habe ich mir mal notiert...