Hallo Besucher, der Thread wurde 7,3k mal aufgerufen und enthält 37 Antworten

letzter Beitrag von electronic-man am

Hilfegesuch & Programmvorstellung: Xumgui - ein Linux/GTK3+ GUI für xum1541/OpenCBM-Tools

  • Hallo!


    Ich habe ein kleines Tool gebaut, mit dem man mal die OpenCBM-Tools unter Linux per Maus bedienen können soll. Im Moment wird nur d64copy unterstützt, zu finden unter dem Reiter "Copy Tracks".
    Es gibt als kleinen Bonus auch eine Verify-Funktion, die arbeitet indem das vom PC zur 1541 übertragene Image wieder zurückgelesen und mit dem Original-D64-File verglichen wird. Damit das Tool funktioniiert muss d64copy im $PATH oder im selben Ordner wie xumgui liegen. Die anderen Tabs sind noch funktionslos.


    Ich habe seit Jahrzehnten nicht mehr programmiert, und keine Ahnung von Python, keine Ahnung von PyCharm, sowie ebenfalls keine Ahnung von Github, und hoffe deshalb, dass mir jemand etwas unter die Arme greifen kann, oder vielleicht dabei mithilft, den Code zu säubern um das Tool einfacher weiter entwickeln zu können. :)


    Es ist in Python 2.7 geschrieben, das GUI habe ich mit Glade 3.20 konstruiert und wird über GTKBuilder eingeladen.
    https://github.com/Lalarian/xumgui



    Mir bekannte Probleme sind:
    -Der Code wird schon jetzt (wo erst ein kleiner Teil der Features implentiert ist) unübersichtlich. Z.B. stören mich die globalen Variablen. Aber auch die Imports sind chaotisch, und es gibt sicher noch einiges Andere aufzuräumen.
    -Ich finde Github kompliziert, trotz der Verwendung über die PyCharm IDE. Z.B. habe ich xumgui.py über ein Terminal zu xumgui.pyc kompiliert, aber weiß bisher nicht, wie ich es erreiche, dass diese Datei, die im selben Ordner wie die Source-Files liegt, auch in PyCharm angezeigt und zu Github hochgeladen werden kann.
    -Es gibt Fehlermeldungen wegen nicht deklarierter Variablen, die dennoch verwendet werden, was teilweise auch Auswirkungen hat, z.B. dass der Output-Textbuffer während eines Übertragungsvorgangs gelegentlich nichts anzeigt.
    -Eine Menge anderer Dinge, die man sicherlich eleganter und/oder zuverlässiger lösen könnte.
    -Und eine Menge fehlender Features, wobie der Schwerpunkt wohl schon auf d64copy liegt.
    -Ich könnte ein gutes und exakt frontales und zentriertes Bild einer alten (braunen) 1541 gebrauchen, die gefällt mir einfach besser als meine 1541c (außerdem bin ich kein guter Fotograf. der so ein Foto ohne Glanz hinbekäme), die ich erst einmal als Symbol für die Laufwerksauswahl verwendet habe. Würde mich freuen, wenn jemand ein gutes Foto einer dunklen 1541 für die Verwendung in xumgui zur Verfügung stellen könnte!
    -Auch gibt es bisher keine Lizenzangaben o.ä. Sollte ich da etwas machen? Kennt sich da jemand aus, bzw. könnte etwas aufstellen?
    -Wie ist das mit Abhängigkeiten? Ich musste einige libraries und Python-Addons bei mir zur Entwicklung installieren, läuft es bei euch? (xumgui.pyc?)
    -Eine sinnvollere Zuordnung von Funktionen und deren Parametern, um die Wiederverwendbarkeit von SUBs im Tool zu verbessern.


    Eine kompilierte Datei (xumgui.pyc) habe ich erst einmal hier angehängt, bis das Problem mit derem Upload zu Github gelöst ist!
    Wäre toll, wenn da jemand helfen könnte! :)


    Grüße,

  • Naja - den ersten Post hatte ich z.B. gar nicht mitbekommen, weil die Themen auf der Hauptseite so schnell überholt sind.
    Ich finde CBMxFER als grafische Oberfläche unter WIN auch nicht so dolle. Aber wer, der einen C64 ohne FC3 bedienen kann, braucht ernsthaft ein grafisches FrontEnd für OpenCBM?
    Ich würde mir bei viel Langeweile eine Batch mit den wichtigsten Funktionen und Menü in TakeCommand/TCC LE basteln. Aber.... mehr als cbmforng und nibwrite brauche ich sowieso nicht. Alles andere geht wahnsinnig comfy mit DirMaster.
    Linux habe ich jenseits der Serverfunktionen abgeschrieben. Und wer es benutzt, tippt die kleinen Kommandos sicher mühelos.



    Das als Fallbeispiel ohne Anspruch auf repräsentativen Charakter, warum vielleicht die Resonanz fehlte.

  • Danke dir für das Feedback. Es gth hier natürlich hauptsächlich darum, dass es bisher für Linux kein bisschen Komfort gibt. Und immerhin bekommt man noch ein Verify-Feature als kleines Extra. Nachdem das erste mal ein Spiel abgestürzt ist, das ich zuvor vom PC transferiert hatte, wusste ich Verify zu schätzen; natürlich um mindestens einschätzen zu können, ob das Problem jetzt am Transport der Daten oder meinem C64 lag. Dir Master ist leider unter Linux nicht vorhanden und läuft auch unter Wine eher schlecht als recht.
    Dachte dass hier vielleicht mehr Linux-Nutzer unterwegs sind, weil ja viele Leute hier auch selbst programmieren und basteln, also eher schon zur etwas enthusiastischeren Kategorie zählen. :)

  • Es gth hier natürlich hauptsächlich darum, dass es bisher für Linux kein bisschen Komfort gibt.

    Das unterschreibe ich sofort.
    Nach 10 Jahren setze ich für die Arbeit einen neuen Server auf. Keine Nischendistribution, sondern CentOS. Da kann ich wieder alles von Hand machen. Vor 10 Jahren hatte ich die alte Kiste auf Fedora 9(?) 13?? aufgesetzt, und da konnte ich wenigstens alle Grundeinstellungen grafisch machen und händisch nachbessern. Aktuelles CentOS?! Nix. Da bastel ich also wieder im joe, den ich manuell von einem manuell hinzugefügten Repo installieren konnte, die Config für alle Dienste zusammen. Reicht dann hoffentlich wieder 10 Jahre... :S

  • Gut, dass du es auch so siehst, so erspart sich hier der Disput. Allerdings will ich noch anmerken, dass ich mich mit diesem Satz eigentlich nur auf OpenCBM bezogen habe; nicht dass hier doch noch ein Krieg vom Zaun bricht :)
    Linux ansonsten ist - naja, man gewöhnt sich daran. Windows kommt für mich nicht mehr ernsthaft in Frage nach dem was Microsoft daraus gemacht hat (Spionagetool, das mehr und mehr wichtige Features immer schwieriger zugänglich macht), Apple sowieso nicht und da bleibt ja nicht mehr viel übrig...

  • Mach' ich, danke dir! :)


    PS, nur aus Neugier: mit "gerendert" meinst du aus CGI? Oder meinst du damit nachbearbeitete Fotos? Heute wird der Begriff "Rendern" ja für Vieles verwendet, wobei ich ich aus dem "sieht dann wie echt aus" ja eher folgern würde, dass es sich um CGI handelt.

  • Ich habe Dir vier Ansichten von vorne erstellt. So könnte man noch den Status an der Floppy anzeigen lassen.

    • Power OFF
    • Power ON
    • Power ON / mit Floppy
    • Power ON / mit Floppy / LOADING


    Die Zahlen würde ich eventuell nicht ins Bild einbauen. Es sind PNGs ohne Hintergrund. Kann man also noch alles mögliche mit machen.


    Link zu den PNGs: https://www.dropbox.com/s/w3ok…oppy_1541_FRONTs.zip?dl=0



  • Hallo!


    Ich musste mein Arbeitssystem (jetzt Xubuntu 18.04) komplett neu aufsetzen, weil das Update von 17.10 nicht funktionierte. Bisher habe ich die Python Entwicklungsumgebung nicht neu eingerichtet.
    So lange es kein Feedback in Form von Featureanfragen oder Bugfixes gibt, sehe ich es deshalb erst Mal als abgeschlossen (Es kann per d64copy Images schreiben und lesen).


    Wenn es denn entsprechende Nachfrage gibt, werde ich mir die Mühe machen die Sache wieder in Angriff zu nehmen und die neuen Bilder einbauen.
    Hast du denn Interesse an weiteren Features?
    Grüße

  • Hi ! Bin gerade durch Zufall über das Thema hier gestolpert. Ich finde es toll wenn sich jemand auch für uns Linuxer die Mühe macht für gängige Tools eine vernünftige GUI zu machen.
    Werde das heute Abend mal ausprobieren.

  • Frage: Wie starte ich das denn am besten ?


    per python xumgui.pyc


    bekomme ich folgende Fehlermeldung:
    Traceback (most recent call last):
    File "xumgui.py", line 19, in <module>
    ImportError: No module named psutil


    opencbm ist die aktuelle V99

  • Ah, das erste Feedback, danke! :)


    Versuche mal das psutil modul so zu installieren (Das Modul wird übrigens nur benötigt um den durch den eventuell gelegentlich hängenden USB-Transfer ebenfalls hängenden opencbm Prozess zu beenden; ist ja leider ein bekanntes OpenCBM-Problem).
    sudo pip install psutil



    Und gucken ob es danach klappt.
    (Gestartet hast du es richtig).