Hallo Besucher, der Thread wurde 29k mal aufgerufen und enthält 241 Antworten

letzter Beitrag von giana-sisters am

New Release: Vice 3.2 - r35190 (Gtk3)

  • Ich kenne das Win32 API recht gut, genau deshalb kann ich auch sagen, dass niemand damit freiwillig ein GUI baut, das über ein Fenster mit drei Buttons hinausgeht.

    Deshalb schrieb ich in meinem ersten Post zu diesem Thema ja auch:

    Die Windows API ist extrem simpel, vor allem bei so Dingen wie WinVice, wo es nicht viel Besonderes auf der Oberfläche gibt.

    Die GUI von Vice hat nicht viel mehr Elemente als ein paar Menüs, Buttons und ein paar Dialoge. Das mit der Win32API zu realisieren ist halt nicht schwer. Sicherlich sind die meisten modernen Toolkits komfortabler, aber darum ging es hier überhaupt nicht.


    Nicht falsch verstehen: ich bin mir bewusst, dass die WIN32API die Portabilität von Vice nicht gerade fördert und deshalb ist es klar, dass ein portables Toolkit her muss.

  • Du hast aber schon mitbekommen, dass die VICE-Entwickler einen gewissen Wert darauf legen, dass der Emulator auf vielen Plattformen lauffähig ist und nicht nur auf einer einzigen, die von den Entwicklern nicht verwendet wird?

    8|

  • Die GUI von Vice hat nicht viel mehr Elemente als ein paar Menüs, Buttons und ein paar Dialoge. Das mit der Win32API zu realisieren ist halt nicht schwer. Sicherlich sind die meisten modernen Toolkits komfortabler, aber darum ging es hier überhaupt nicht.

    Die ist nicht so klein, wie du meinst (da sind auch so einige Dialoge, sowohl standard als auch custom, das Fenster für den Monitor, usw). Und wir haben offenbar eine sehr unterschiedliche Definition von "einfach". Oder vielleicht ignorierst du auch solche netten Problemchen wie z.B. in dem Testcode von mir, den ich oben zitiert habe (Wahl des richtigen Font, "visual styles", dazu Kompatibilität mit verschiedenen Auflösungen (DPI, nicht Größe), Integration mit dem murksigen Message-Loop, usw). Ohne in den Code von Vice 3.2 zu schauen würde ich mal behaupten: Da ist sehr viel Code für das Windows UI, und der ist sicher alles andere als bugfrei.(*)

    Nicht falsch verstehen: ich bin mir bewusst, dass die WIN32API die Portabilität von Vice nicht gerade fördert und deshalb ist es klar, dass ein portables Toolkit her muss.

    Ja, also man KANN das schon portabel halten, wurde bisher ja auch gemacht, aber das heißt eben mehrere UIs pflegen. Und das win32 UI ist davon mit Sicherheit das problematischste und hässlichste. Genau das sind dann ja die Gründe, nur noch ein UI anzubieten, eben eines, das auf einem cross-platform Toolkit läuft. Muss ich dir aber offensichtlich nicht erklären ;) Allerdings vielen anderen hier ....


    Deshalb nochmal zurück zu einer früheren Aussage von mir: Anstatt zu meckern sollten wir uns alle über diese Entscheidung freuen, denn auf lange Sicht wird sie dazu führen, dass die Entwickler frei gewordene Zeit nutzen können, am Emulator selbst zu arbeiten, statt einen Zoo von UIs zu supporten :)


    ---
    (*) einer davon schlägt sehr deutlich auf dem Surface Book zu, das ich von der Arbeit habe: Das Display hat eine Auflösung jenseits der 200DPI, vice ignoriert das, um irgendwas zu lesen braucht man eine Lupe.

  • Eines der Probleme mit der Portierung, die ich habe, ist dass man ja leider mit unsäglichen makefiles und einem Linux-Subsystem rumhampeln muss. Ich habe VICE schon mit dem WSL compiliert bekommen, aber da ich in der Umgebung nicht so fit bin, müsste mir jemand erklären, ob und wie ich da vernünftig(!) mit debuggen kann.


    Ich bilde mir schon ein, einen Komfort-Editor (IDE) mit eingebauten Debugger verwenden zu wollen. Auf Kommandozeilen- oder printf-Debuggen kann ich gerne verzichten. Auch wenn das einige ältere Semester irgendwie für sinnvoll erachten, wie vor 30 Jahren zu programmieren, die Welt hat sich halt weitergedreht.

  • Ich kann nur immer empfehlen sich alle Systeme mal anzuschauen und dann zu entscheiden was besser zu einem passt. Ich habe z.B. erst durch Linux und OSX, Windows richtig zu schätzen gelernt. Auch wenn solch eine Meinung natürlich gerne zerrissen wird. Das gilt wohlgemerkt auf dem Desktop, als Webserver würde ich wiederum Linux einsetzen(allein aus Gewohnheit) oder auf kleinen SoC Systemen oder so. Apple gefällt mir auf Smartphones und Tablets gut, auch wenn mir das zu teuer ist. Ein andere User sieht für sich da einen andere Kombination als Favorit.


    Ja sei es drum, jeder halt so wie es ihm am besten gefällt.

  • Ja, also man KANN das schon portabel halten, wurde bisher ja auch gemacht, aber das heißt eben mehrere UIs pflegen. Und das win32 UI ist davon mit Sicherheit das problematischste und hässlichste.

    Das mag stimmen, aber die native Win-Version ist halt genau die, welche die mit Abstand meisten User verwenden. Und das ist halt das Verheerende an deren Abschaffung, man schafft quasi den "Anführer" ab, der durch jahrzehntelange Updates insgesamt schon wirklich ausgereift war, mal von ein paar Wehwehchen abgesehen. Es ist Mist, dass sich da niemand finden ließ, der die Win32-UI weiterhin pflegen wollte.


    Die VICE-Programmierer scheinen ja auch weiterhin noch nach jemandem zu suchen in der Hinsicht - siehe den letzten Post von "angryking".


    Was man bräuchte wäre ein Windows GUI Programmierer außerhalb von Vice, der sich die Source schnappt und was richtig modernes um den Emulator Core baut.


    Gute Idee. Vielleicht sollte man da mal einen Spendenaufruf im Forum starten? Würde ich sofort gleich mal 20,- Euro spenden für, wenn es da eine Chance gäbe.

  • Ich glaube nicht das dieses "ich will aber haben, Forum" die passende Beschwerdeplattform für den Vice Emulator ist.
    Das ist ein OS Projekt. Das Ding lebt vom Mitmachen, nicht davon Forderungen zu stellen.

  • Eines der Probleme mit der Portierung, die ich habe, ist dass man ja leider mit unsäglichen makefiles und einem Linux-Subsystem rumhampeln muss.

    Meines Wissens sollte es auch mit msys2 unter Windows compilierbar sein statt via WSL zu crosscompilieren.


    Zitat

    Ich habe VICE schon mit dem WSL compiliert bekommen, aber da ich in der Umgebung nicht so fit bin, müsste mir jemand erklären, ob und wie ich da vernünftig(!) mit debuggen kann.

    Ich habe exakt gar keine Ahnung von Debugging unter Windows, meine aber gelesen zu haben, dass hinreichend neue Versionen von clang Microsoft-kompatible Debug-Informationen ins Binary schreiben können.

  • Unseen: Danke für die Info!


    Das wäre halt meine Traumvorstellung, da mit Visual Studio durchgehen zu können. Damit komme ich halt von Berufs wegen am besten klar. Wenn's gar nicht anders geht, würde ich auch Eclipse verkraften.
    Wäre mal einen Versuch wert.

  • Nochmals übrigens.


    Also ist die 3.3 eigentlich praktisch schon da, bei Pokefinder. Wird ja höchstens noch an der Doku oder so geändert.
    Wozu dann der letzte Link trotzdem gut sein soll, weiss ich nicht.

  • Das ist ein OS Projekt. Das Ding lebt vom Mitmachen, nicht davon Forderungen zu stellen.


    Naja, nicht jeder kann programmieren. Ich schrieb ja zum Thema Win32-Version im letzten Post: "Vielleicht sollte man da mal einen Spendenaufruf im Forum starten". Mehr als spenden, Bugreports geben oder Vorschläge machen, kann man von aussen nur schwer machen, wenn man kein Programmierer ist. Aber diskutieren ist eigentlich immer gut.



    Also ist die 3.3 eigentlich praktisch schon da, bei Pokefinder. Wird ja höchstens noch an der Doku oder so geändert.


    Das hört sich gut an. Werde ich nachher mal ausprobieren den Link.


    Nachtrag: Ist aber noch nicht downloadbar bislang eine WinVICE 3.3 Version, der Link führt jedenfalls nicht zu einer downloadbaren Version und auch bei Pokefinder findet man nichts.

  • Das mag stimmen, aber die native Win-Version ist halt genau die, welche die mit Abstand meisten User verwenden. Und das ist halt das Verheerende an deren Abschaffung, man schafft quasi den "Anführer" ab, der durch jahrzehntelange Updates insgesamt schon wirklich ausgereift war, mal von ein paar Wehwehchen abgesehen. Es ist Mist, dass sich da niemand finden ließ, der die Win32-UI weiterhin pflegen wollte.

    Ich weiß echt nicht, wie du auf solchen Krempel kommst. Erstens ist da nichts "ausgereift", höchstens die Bugs sind gereift. Und zweitens wird nicht die Windows-Version abgeschafft, sondern es wird in Zukunft auf Windows das gleiche UI-Toolkit verwendet wie auf anderen Systemen. Was am Ende zu weniger Bugs führt. Sorry, aber da juckt es echt in den Fingern: Das ist einfach Blödsinn, was hier in weiten Teilen des Threads behauptet wird.

    Die VICE-Programmierer scheinen ja auch weiterhin noch nach jemandem zu suchen in der Hinsicht - siehe den letzten Post von "angryking".

    Ja, für den Windows-Port. Sicher auch mit dem Ziel, weiterhin fertige Windows-Binaries anzubieten. Ziemlich sicher NICHT, um das native-win32 GUI weiterleben zu lassen -- DAS ist ein für alle mal beerdigt, und wer immer noch nicht versteht, warum das gut so ist: Ein Blick in meinen win32 Beispielcode weiter oben sagt mehr als tausend Worte.

    Steht doch da. Die Windows Version wird keine offizielle Version mehr auf der Seite bekommen.

    ... womit eigentlich nur ein Stück Normalität einkehrt. Fertige Binaries werden für viele andere Plattformen auch nicht angeboten, das Release ist der Source. Nun hat man auf einer Standard Windows-Installation blöderweise keine Toolchain zum kompilieren von Software, ganz im Gegensatz zu vielen anderen Systemen, das ist schon klar. Aber die Erfahrung zeigt: Wenn das Projekt selbst keine Binaries anbietet, tun es andere. So geschehen unter anderem bei GIMP, bevor man dort selbst Binaries angeboten hat, und z.B. aktuell bei Chromium.


    Allerdings, um auch kurz auf @Endurion einzugehen: Neben einem C Compiler (in der Regel gcc oder clang) braucht VICE nur "irgendein" make und eine bourne-kompatible Shell. Das kriegt man in der Tat ganz einfach mit MSYS2 auf seinen Windows-Rechner. Verwendet werden nämlich die GNU autotools (IMHO ja ein grauenhaftes Monstrum, hat aber den Vorteil, dass die genannten Komponenten für jedes Zielsystem ausreichen). Übrigens, wer über "make" meckert, hat sich in der Regel noch nicht besonders weit damit beschäftigt: Es ist eines der mächtigsten build tools überhaupt. Microsofts XML-basiertes MSBuild ist ein schlechter Witz dagegen. Und was an gdb schlecht sein soll müsste auch mal jemand etwas konkreter erklären. Gdb hat ein command line interface (ein ziemlich gutes übrigens, habe damit schon viel debuggt), aber auch eine Schnittstelle für IDEs (klar kann es manchmal von Vorteil sein, in einem IDE zu debuggen). Kann man logischerweise beides mit VICE verwenden. Soweit ich weiß gibt es sogar für Visual Studio eine Gdb-Anbindung, damit habe ich aber keine Erfahrung.

  • Bis auf Weiteres nutze ich WinVICE. Durch Wiggeligkeiten ist die GTK-Version für mich produktiv unbrauchbar. Das Fenster zeigt zwar 50fps an, aber Scrolling ruckelt deutlich, im Vollbild-Modus ist die Darstellung mit aktiven CRT-Rendering für den Hintern (in 1080p geht das noch halbwegs, aber bei niedrigeren Auflösungen schaut es furchtbar aus). Irgendwas ist auch noch mit dem Sound. Ich meine nicht Unterschiede in der SID-Emulation zwischen 2.4 und 3.x, z.B. in der Demo C=Bit 18 im Part mit dem rotierenden Joystick ein ständiges Knacken, was da nicht hingehört.


    Was ich allerdings nicht nachvollziehen kann, ist die Kritik am GUI von GTK-VICE. Das UI war schon in WinVICE 2.4 nicht toll, die Änderungen in 3.x machen es nicht übersichtlicher - alleine das Scrolling im Settings-Menü... Das Layout von GTK-VICE ist ein Quantensprung dagegen. Nicht nur relativ gesehen, mMn ist das Settings-Menü ziemlich gut strukturiert. Nun gut, die Buttons verströmen etwa den Charme von Windows 98. Das schafft aber so manche professionelle Software heutzutage ebenso und wenn das wirklich ein Problem sein soll, kann man da nichts ändern? Gute Designer hat die C64-Community ja nun einige.


    Zum GTK-VICE fällt mir gerade ein: Wie pausiert man die Emulation? Wie regelt man die Geschwindigkeit? Die Tastenkombinationen scheinen teils nicht deckungsgleich mit WinVICE zu sein, im Menü fehlen diese Funktionen und das Manual ist in der Beziehung nicht hilfreich.