Damit es nicht so aussieht, als ob ich dich ignoriere: Leider kann ich dazu nichts sagen.
Aber ein anderes Thema, das mir aufgefallen ist: Einige wenige Befehle bzw. Funkgespräche werden unter Wine nicht angezeigt, das Fenster bleibt weiß. Das betrifft Befehle, die nicht als HTML-Datei erstellt werden, sondern direkt als PNG-Datei (
laut Zusi-Doki ist das nicht vorgesehen, "Die angezeigte Datei muss im html-Format erstellt sein und wird in einem in Zusi integrierten Fenster des Internet-Explorers angezeigt", funktioniert aber unter Windows). Ein betroffener Zug ist 79706 im Fahrplan Luitpoldhuette-Klardorf_2022_06Uhr-10Uhr.fpn, direkt am Anfang wenn von der Abstellung zum Bahnsteig rangiert werden soll.
Ein Workaround ist, mittels regedit im Wine-Präfix unter "HKEY_CLASSES_ROOT\MIME\Database\Content Type\image/png" einen Schlüssel "CLSID" mit dem gleichen Inhalt wie z.B. in "image/gif" anzulegen. Ist aber nicht für das "Upstreaming" in wine geeignet, weil unter Windows dieser Schlüssel für image/png auch nicht existiert.
Meine Versuche, einen unter Windows funktionierenden und unter Wine fehlschlagenden Test für das PNG-Laden in einem "ieframe" zu erstellen, den wine für die Anzeige der Befehle nutzt, haben mich dann beinahe in den Wahnsinn getrieben. Es schien einfach keine Konfiguration des Tests unter Windows zu laufen. Bis ich dann gestern bemerkt habe, dass es unter Windows 10 eben manchmal tatsächlich auch nicht funktioniert: Während das Windows auf meinem eigenen Rechner, der meistens Ubuntu ausführt, PNG-Dateien in einem ieframe völlig problemlos anzeigt und auch das Erstellen eines funktionierenden Tests daher leicht ist, weigert sich der andere Windows 10-Rechner im Haushalt, den ich i.d.R. für die wine-Tests nutze, beharrlich. Statt die PNG-Datei anzuzeigen, erscheint nur eine weiße Seite und es öffnet sich stattdessen ein Download-Dialog für die PNG-Datei. Deshalb schlugen dort auch die ganzen Test-Bastelversuche bei nicht sichtbarem Fenster immer fehl.
Hier hat jemand das gleiche Phänomen in einer anderen Software bemerkt.
Meine aktuelle Theorie für die Sache ist jetzt, dass Zusi normalerweise das Webview2 nutzt, welches auf Edge basiert und kein Problem mit PNGs hat (das hat Carsten ja für 3.5 bekanntgegeben, wenn ich mich richtig erinnere, und wir haben jetzt auch WebView2Loader.dll-Dateien). Nur wenn Edge nicht verfügbar ist, wie wohl eben bei Nutzung mit Wine, gibt es einen Fallback auf die alte Internet Explorer-basierte "IWebBrowser2"-Lösung. Und hier implementiert zumindest Wine derzeit die Variante, dass PNG-Dateien nicht funktionieren, so wie das wohl teilweise auch unter Windows der Fall zu sein scheint, aber irgend eine Konfiguration gibt es, mit der es dann doch funktioniert – so wie auf meiner Win10-Installation – und vielleicht löst Zusi diese Konfiguration ja auch irgendwie programmseitig aus.
Das doofe an der Situation ist jetzt, dass man die wine-Leute immer am besten von einer Änderung überzeugen kann, wenn man einen automatisierten Wine-Test hat, der demonstriert, dass etwas auf Windows funktioniert und unter Wine nicht. Das dürfte in dem Fall jetzt schwierig werden, denn tatsächlich würde der Test ja auch unter Windows nicht immer funktionieren, falls ich nicht noch herausfinde, wie man Windows zuverlässig davon abbringen kann, die Datei nur zum Download anzubieten. Vielleicht kann man auf recht umständliche Art einen abgespeckten Test basteln, der nur einen Teil der momentan für ieframe-Tests üblichen Dinge prüft (unter Wine gibt es beim PNG-Versuch derzeit einen expliziten Fehler, aber unter Windows nicht, denn es kommt ja immerhin zumindest erfolgreich der Datei-Download-Dialog).