last post from Zirias/Excess at the
Der Bug im Build für XP/Vista ist behoben 
Habe das buggy zip einfach ersetzt, also Direktlink ist nach wie vor http://sekrit.de/v1541commande…n32-xp-vista-1.1+pre1.zip
Dank Plastix ' Test bin ich mir jetzt sehr sicher, dass diese Version auf alten Windows gut funktioniert Das heißt zukünftige Releases werden vermutlich auch so einen Build dabei haben, wobei da immer auch eine Warnung gilt, schließlich ist die verwendete Qt Version auch seit 2019 EOL.
Für interessierte Coder:
Hab mir das nochmnal durch den Kopf gehen lassen....
Klar, wenn man das alles implementieren will, dann wäre das ein riesen Aufwand.
ABER:
Es wäre gar nicht notwendig das Rad nochmal zu erfinden, denn prinzipiell macht z.b. Beyond Compare die Sache ja schon perfekt, solange es um Files in 2 Verzeichnissen auf Windows Ebene geht.
Somit würde es ja eigentlich genügen wenn dein Tool 2 D64 Images öffnen kann, und man sämtliche darin enthaltenen Files mit einem Klick temporär in 2 Verzeichnisse auf Windows Ebene konvertieren könnte.
Anschließend müsste man nur noch die beiden Folder markieren, und 'Beyond Compare Vergleich' wählen, und voila
(evtl. könnte dein Tool das 'Markieren und Vergleichen aufrufen' sogar porgrammatisch erledigen? (ich glaube Beyond Compare kann man auch via Commandline benutzen?)
Also alle Files von einer Disk in ein Verzeichnis kopieren sollte per Drag&Drop schon tun (einfach alles markieren und ziehen) -- wenn du "nur" Dateiinhalte vergleichen willst müsste das fast schon reichen, blöd wird es eben, wenn mehrere gleich heißen, was das CBM DOS ja prinzipiell zulässt....
Ein "windows only" tool möchte ich nicht integrieren, das wäre zu viel plattformspezifischer Kram im Code.
Irgendwann später mal ein wirklich cooles Vergleichsfeature könnte ich mir schon vorstellen, aber wie gesagt, das wäre riesig :o
Hmm, ja, 'manuell' wäre es auf diese Weise schon jetzt möglich, aber ist halt umständlich, weil man extra die Verzeichnisse anlegen, alles markieren, rauszuiehen, usw. machen muss.
Wäre halt super praktisch wenn das vom Tool aus mit einem Klick zu erledigen wäre, und die einzelnen Schritte dann automatisch erledigt werden.
Daß es mit gleichnamigen Files nicht klappen würde wär mir egal, ist ja eher ein Sonderfall und nicht die Regel (gleichlautende DEL File Directory Einträge wären mir egal, geht ja hauptsächlich um PRGs)
Zirias/Excess: Vielen Dank für Deine gute Arbeit. Es ist auch schön, dass Windows XP unterstützt wird. Das System läuft stabil und wenn es nicht mit dem Internet verbunden ist, besteht auch keine Gefahr, dass der Rechner übernommen wird.
Mein Hauptrechner, mit dem ich mit dem Internet verbunden bin, hat OS Linux Mint 19.1. Das kann ich jedem nur empfehlen. 
Kostet kein Geld, ist SICHER und man wird nicht wie bei Windows 10 permanet von MS ausgespäht. Es ist einfach zu bedienen und hat ein Outfit wie Windows 10.
Mit meinem Nebenrechner mit Windows XP betreibe ich ZoomFloppy und jetzt auch V1541Commander. Noch einmal vielen Dank.
mikulask Danke, das freut mich
Es ist auch schön, dass Windows XP unterstützt wird. Das System läuft stabil und wenn es nicht mit dem Internet verbunden ist, besteht auch keine Gefahr, dass der Rechner übernommen wird.
Ich verstehe zwar nicht, was gegen Windows 10 spricht, wenn man Windows nutzen will -- aber ja, ohne Internetverbindung und wenn man sehr genau überprüft, was man manuell aufspielt, kann man es natürlich recht gefahrlos betreiben, wenn man unbedingt will. Wäre da nicht das Problem, dass die letzte Qt-Version, die XP unterstützt hat, ebenfalls EOL ist, dann würde ich ja gern den offiziellen Build XP-kompatibel machen, aber geht halt leider nicht
Mein Hauptrechner, mit dem ich mit dem Internet verbunden bin, hat OS Linux Mint 19.1. Das kann ich jedem nur empfehlen.
Hmm ... du hast nicht zufällig Lust, dafür ein Paket zu bauen? Hehe ...
Wäre da nicht das Problem, dass die letzte Qt-Version, die XP unterstützt hat, ebenfalls EOL ist, dann würde ich ja gern den offiziellen Build XP-kompatibel machen, aber geht halt leider nicht
Das ist für mich fachchinesisch, verstehe kein Wort.
Hmm ... du hast nicht zufällig Lust, dafür ein Paket zu bauen?
Da bin ich leider nicht der richtige für so etwas. Ich bin kein Fachmann der programmieren kann, sondern nur normaler Linux-Nutzer.
Das ist für mich fachchinesisch, verstehe kein Wort.
Vielleicht interessiert es jemanden, also versuche ich es mal allgemeinverständlich zu formulieren
Qt ist eine Bibliothek bzw ein Framework hauptsächlich für GUIs (grafische Oberflächen), kann aber noch andere Dinge, und ist "cross-platform", d.h. man kann sein Programm für Windows, für Linux und eine Menge andere Systeme bauen. Ich verwende das für die grafische Oberfläche von V1541Commander. Übrigens basiert der komplette KDE Desktop auf Qt
Qt wird auch laufend weiterentwickelt, und seit einiger Zeit setzt es in der Windows-Version mindestens Windows 7 voraus. Die letzte Version von Qt, die auch XP und Vista unterstützt hat, war 5.6 -- das war zwar eine LTS (long-term support), aber der Support endete irgendwann in 2019, seither ist diese Version EOL (end of life). Das bedeutet es gibt dafür keinerlei Updates oder Bugfixes mehr, nicht einmal falls es sicherheitskritische Bugs geben sollte. Für mein Tool wahrscheinlich kein allzu großes Problem, es nutzt kein Netzwerk (nur einen lokalen Socket) und Dateien die geöffnet werden behandle ich komplett in eigenem Code. Ein gewisses Risiko für Bugs durch die alte Qt Version besteht aber.
Also baue ich deshalb die offiziellen Releases mit Qt 5.12, das ist die aktuelle LTS, und setzt eben Windows 7 voraus
Da bin ich leider nicht der richtige für so etwas. Ich bin kein Fachmann der programmieren kann, sondern nur normaler Linux-Nutzer.
Schade Ich hoffe es finden sich mal ein paar Linux-User, die Pakete bauen
Eine kleine Neuigkeit für Linux-User, die den fertigen Build benutzen wollen Der hat jetzt eine libfontconfig integriert, die so konfiguriert ist, dass die Systemschriften auf den meisten Linux-Systemen gefunden werden sollten -- im Ergebnis sieht das GUI also "vernünftiger" aus. Ich habe den Prerelease-Build ersetzt, direkter Download ist also hier: http://sekrit.de/v1541commande…ux-x86_64-1.1+pre1.tar.xz
Ich werde es testen, Danke!
Es wäre schön, wenn das d71-Format unterstützt würde.
Liebe Grüße!
ThomBraxton
Es wäre schön, wenn das d71-Format unterstützt würde.
Das will ich zwar nicht ausschließen ... aber wie der Name des Tools und der zugrundeliegenden Library schon verraten konzentriere ich mich erst einmal auf alles mögliche, was mit der 1541 möglich ist. Image-Formate für andere Laufwerke kommen dann vielleicht irgendwann später
Vorher sind aber ein paar andere Dinge auf der Prioritätenliste:
Nicht alles von der Liste muss unbedingt wichtiger sein als Support für Imageformate anderer Commodore Laufwerke -- aber zumindest die Dirart-Geschichte, rohes Editieren, und GEOS + C128 Bootsektor Support finde ich persönlich wichtiger
Moin,
Da bin ich leider nicht der richtige für so etwas. Ich bin kein Fachmann der programmieren kann, sondern nur normaler Linux-Nutzer.
Schade
Ich bin gerade dabei erst einmal für Arch ein "Paket" zu bauen. Die sollen dann auch im AUR landen.
Bin aber erst einmal dabei das für die lib1541img zu schnüren - mir sind da ein paar Fallstricke aufgefallen, die ich beim Package berücksichtigen muss - und dann kommt das GUI Tool.
Ein *.deb muss ich mal schauen - das war auch nicht so schwer, allerdings muss ich mir dazu erst einmal auf einer Maschine oder VM etwas Debian-basierendes installieren.
Btw. Ich habe mir Dein Buildsystem noch nicht genauer angeschaut, aber auf dem ersten Blick scheint es immer in das jeweilige Projekt miteingebunden werden zu müssen?
Ich dachte kurzeitig darüber nach, dass Buildsystem als eigenes Paket zu machen (würde ich dann aber erst in späteren Versionen machen).
Btw. Ich habe mir Dein Buildsystem noch nicht genauer angeschaut, aber auf dem ersten Blick scheint es immer in das jeweilige Projekt miteingebunden werden zu müssen?
Ich dachte kurzeitig darüber nach, dass Buildsystem als eigenes Paket zu machen (würde ich dann aber erst in späteren Versionen machen).
Ne, das ist darauf ausgelegt, als git submodule eingebunden zu werden, eigenes Paket wäre also recht sinnlos. Das ist leider tatsächlich ein bisschen blöd beim Paketieren, weil Github keine Funktion hat, einen tarball mit submodules rauszugeben 
-- ist mir auch beim Port für FreeBSD aufgefallen. Ich hab das da mit einer kleinen custom rule nach dem Entpacken gelöst:
https://bugs.freebsd.org/bugzi…cgi?id=211456&action=diff (Zeile 29 im Makefile)
Ein *.deb muss ich mal schauen - das war auch nicht so schwer, allerdings muss ich mir dazu erst einmal auf einer Maschine oder VM etwas Debian-basierendes installieren.
Na DEN Aufwand könnte ich auch selbst betreiben Meine Hoffnung war, dass das einfach jemand macht, der sowieso so ein System nutzt
Btw. Ich habe mir Dein Buildsystem noch nicht genauer angeschaut, aber auf dem ersten Blick scheint es immer in das jeweilige Projekt miteingebunden werden zu müssen?
Ich dachte kurzeitig darüber nach, dass Buildsystem als eigenes Paket zu machen (würde ich dann aber erst in späteren Versionen machen).
Ne, das ist darauf ausgelegt, als git submodule eingebunden zu werden, eigenes Paket wäre also recht sinnlos. Das ist leider tatsächlich ein bisschen blöd beim Paketieren, weil Github keine Funktion hat, einen tarball mit submodules rauszugeben
Dachte ich mir so schon Ist aber für das Arch-Paket kein Problem.
QuoteNa DEN Aufwand könnte ich auch selbst betreiben
Naja, ich habe schon Systeme mit Debian, aber das sind meine Server und da werde ich das Paket nicht bauen
Ich muss mir aber eh für andere Zwecke noch eine Maschine aufsetzen - daher wäre es nicht so dramatisch; ist halt nur nicht zeitnah
Ich bin gerade dabei erst einmal für Arch ein "Paket" zu bauen. Die sollen dann auch im AUR landen.
Da hat übrigens schon jemand was gebastelt: https://aur.archlinux.org/packages/v1541commander/ -- allerdings halte ich es für keine gute Idee, die lib1541img auf diese getrickste Art statisch zu linken :o Leider hat der Paketierer auf meine Mail bisher nicht reagiert
ich muss noch etwas mit dem Mimetypen fixen
Hi, kannst du mir erklären, was da "gefixt" werden muss? Gerne auch per PM ... nur für den Fall, dass ich da upstream was falsch gemacht habe?
ich muss noch etwas mit dem Mimetypen fixen
Hi, kannst du mir erklären, was da "gefixt" werden muss? Gerne auch per PM ... nur für den Fall, dass ich da upstream was falsch gemacht habe?
"Fixen" ist wohl übertrieben und ich glaube auch nicht das im Upstream was falsch ist
Ich muss mir Dein Buildsystem nur noch einmal anschauen (es sei Du kannst gleich adHoc die Antwort geben), damit der Anteil "update-mime-database" nicht ausgeführt wird vom "strip" target.
Die Database Aktualisierung muss ich im Post-Install machen. Auf die Schnelle habe ich das jetzt mit einem sed gelöst, bevor der Package-Build startet.
Ich denke es wird da aber noch eine etwas saubere Lösung für geben (irgend ein Flag o.ä. dem Make übergeben).
