@GiJay: Und wieder eine Runde Anmerkungen: `os.path` und `winsound` werden importiert, aber nicht verwendet. Wobei man statt `os.path` eher `pathlib` verwenden sollte in neuem Code.
Dann wieder Namen: `AnnesAppDir` ist ein Package und kein Verzeichnis. Ja, auf dem Datenträger ist das ein Verzeichnis, aber das muss nicht so sein, man kann Packages beispielsweise auch in Ziparchive packen und im Grunde auch den Importmechanismus beliebig erweitern das Packages von ganz wo anders kommen. Beispielsweise aus einer Datenbank oder über das Netz geladen werden. Aber selbst auf der Festplatte nennt man Verzeichnisse üblicherweise nicht `…Dir` weil diese Information ob das ein Verzeichnis, eine Datei (oder was noch spezielleres) ist, schon im Dateisystem selbst hinterlegt ist.
Namenskonvention für Packages ist auch klein_mit_unterstrichen. Und `ini_file_name` sollte als Konstante KOMPLETT_GROSS sein. Siehe auch:
Style Guide for Python Code.Botz
Bei `OwnToolBox` ist das `Own` so ähnlich wie `My`. Kann es denn dort noch andere `ToolBox`-Packages oder Module geben? Und warum wären das nicht die Eigenen, denn das Package ist ja von Dir‽ Fremde Werkzeugkästen hätten da ja nichts zu suchen.
Die Namen die da importiert werden sind alle wie Klassen geschrieben, also ”Dinge” im weitesten Sinne, sind inhaltlich aber alles Tätigkeiten, also eigentlich Namen bei denen man Funktionen erwarten würde. Wenn es Funktionen sind, sollte die Gross-/Kleinschreibung entsprechend angepasst und Unterstriche eingefügt werden. Sollten es Klassen sein, dann sollten die Namen keine Tätigkeiten beschreiben sondern die ”Dinge” die von den Klassen modelliert werden.
Bei den beiden Fensteranordnungs-`Action`\s wird bei Auslösen jeweils eine Methode aufgerufen, die jeweils ihrerseits nur eine Methode mit den gleichen Argumenten (in diesem Fall keine) aufrufen. Den Zwischenschritt kann man sich sparen.
Wenn man die GUI von Hand schreibt, kann man ausnutzen, dass die Anbindung an die Qt-Bibliothek erlaubt beim Erstellen von Qt-Objekten sowohl Properties als auch Signalverbindungen als Schlüsselwortargumente direkt beim Erstellen der Objekte anzugeben. Im ersten Fall einfach den Propertynamen verwenden, im zweiten einfach nur den Signalnamen. Also beispielsweise:
Code: Alles auswählen
button = QPushbutton("Activate me")
button.setCheckable(True)
button.clicked.connect(do_something)
# =>
button = QPushbutton("Activate me", checkable=True, clicked=do_something)
Ich habe hier gerade kein Qt auf dem Rechner darum kann ich nur sagen was ich im Quelltext sehe/vermute. Es wird recht sicher eine Fehlermeldung geben. Programme sollte man am besten immer ausserhalb einer IDE in einem Terminalfenster starten. Zum einen kann man dann sicher sein, dass die IDE keinen Einfluss hat und Ergebnisse verfälscht, zum anderen sieht man dort bei GUI-Programmen Fehlermeldungen die als Text ausgegeben werden.
`MakeSubwindowSetup` ist ein Hauptfenster, denn das erbt von `QMainWindow`. Was soll in diesem Fenster angezeigt werden? Ich vermute mal Du willst da gar kein Fenster also macht das erben von QMainWindow keinen Sinn. In der `__init__()` wird dann versucht ein `QMDISubWindow`-Objekt zu `self.main_space` hinzuzufügen — und spätestens *das* sollte dann zu eine `AttributeError` führen, der im Terminal ausgegeben wird, aber nicht zum Abbruch des Programms führt. `MakeSubwindowSetup` hat kein `main_space`-Attribut. Das hätte entweder `QMainWindow` schon haben müssen, dann hätte man das an der Stelle von dort geerbt, oder es hätte vorher in der `__init__()` angelegt werden müssen. Da die Methode ja kein *neues* `QMDIArea` erstellen soll, vermute ich mal, sondern das im bestehenden ersten Hauptfenster zum dortigen `QMDIArea` hinzugefügt werden soll, müsste man *das* an `__init__()` übergeben.
Aber auch das scheint mir nicht sinnvoll, denn es sollte wohl eher so sein, dass Du eine eigene Klasse von `QMDISubWindow` ableiten möchtest und ein Exemplar davon in Deiner Hauptfensterklasse erstellen und dort `self.main_space` hinzufügen möchtest.
Wobei ich an der Stelle mal anmerken möchte, dass ich persönlich von dem MDI-Konzept nicht so wirklich viel halte und zumindest versuchen würde an der Stelle die ”inneren” Fensterinhalte einfach in von `QWidget` abgeleitete Klassen zu stecken, so dass man sich entscheiden kann ob man das in einem echten Fenster oder in so einem MDI-Bereich anzuzeigen.
Die Abneigung gegen MDI kommt nicht nur daher, dass das Konzept eigentlich mal von Photoshop kam wo es im Original auf dem Mac tatsächlich normale Fenster gab und die Mac-Typische *eine* Menüleiste oben auf dem *Desktop*. Und als das nach Windows portiert wurde, haben die Entwickler überlegt wie sie das lösen, und haben dann ein Windowsfenster mit der einen Menüleiste genommen und die Fenster alle in dieses eine Fenster gesperrt.
Heutzutage, wo es nicht unüblich ist, dass man mehr als einen Monitor verwendet, ist das echt nervig, wenn man MDI-Anwedungen hat, die in *einem* Fenster auf *einem* Monitor leben müssen, und man nicht ”innere” Fenster davon mal eben auf den zweiten Monitor ziehen kann. Oder was ich auch öfter bei Mehrfensteranwendungen mache: das Hauptfenster auf allen Desktops anzeigen, und Unterfenster pro X (X=Kunde, Ticket, Bearbeitungsvorgang) aufmachen, so dass man zwar mehrere Sachen mit mehr als einem Fenster gleichzeitig in Bearbeitung haben kann, das aber nicht alles auf einmal auf dem Desktop zu sehen ist. Oder gar in *einem* Fenster auf nur einem Monitor.
