@3ff:
Ich bin mir nicht sicher, ob hier nicht ein grundlegendes Verständnisproblem vorliegt. Zumindest suggeriert mir philistions letzter Post eine neue Leseart Deiner Beträge mit diesem Verdacht. Bitte korrigiere mich, wenn dem nicht so ist.
Deine Posts deuten irgendwie auf Qt == Designer == Programmgenerator hin. Dein häufiger angesprochenes "Bild" deute ich als mit dem Designer erstellte Programmoberfläche. Mit dieser Deutung macht zumindest die Überschrift "Qt4 mit Python beleben" Sinn.
Sollte ich Qt in irgendeiner Weise definieren müssen, käme wahrscheinlich etwas wie "plattformübergreifende C++-Bibliothek mit GUI-Schwerpunkt und eigener Entwicklungsumgebung" raus. Dabei deckt die Bibliothek Sparten wie XML, Datenbankzugriffe, Threading, Webzugriff, Graphicsengine (auch mit 3D) und und und ... ab (Ein Blick in die Qt-Dokumentation verschafft da einen Überblick über die erstaunliche Funktionsvielfalt.) All das kannst Du auch ohne Einsatz der mitgelieferten Entwicklungstools nutzen, einfach Editor Deiner Wahl anschmeissen, den Code selber hacken und mit Deiner build-Umgebung kompilieren lassen. Da ist zunächst kein Designer oder Programmgenerator im Spiel.
Der Designer ist eines der mitgelieferten Entwicklungstools und der Einsatz ist optional. Er dient einzig und allein dazu, ein "Bild" Deiner Programmoberfläche/Widgets zu erstellen und mit minimaler Logik zu versehen (Signal/Slot-Verbindungen, Headerdatei). Die eigentliche Programmlogik muss nach wie vor mit Standardmitteln implementiert werden (Slot-Methoden, für das Pythonbinding halt mit Mitteln der Pythonstandardbibliothek
). Desweiteren gibt es Situationen, wo Du mit den Boardmitteln des Designers nicht weiterkommst und die auch die grafische Repräsentation zu Fuß implementieren musst wie oben beschrieben. Für häufiger benutzte Widget-Eigenentwicklungen lohnt sich dann evtl. die Erweiterung des Designers über Platzhalter-Klassen oder sogar die Erstellung eines eigenen Designerplugins.
Der Designer erstellt aus der zusammengeklickten Oberfläche eine XML-Datei, welche dann vom "Programmgenerator" entweder zur Kompilierzeit in C++-Code (
uic - user interface compiler) oder zur Laufzeit in Maschinencode (Klasse
QUiLoader) übersetzt wird.
Für die Benutzung des Designers sind in der Tat keine C++-Kenntnisse erforderlich, allerdings ist die Vorstellung, wie die Widgets im einzelnen ticken, sinnvoll und machen das Arbeiten damit einfacher.
Soviel aus C++-Sicht, bei den verschiedenen Sprach-Bindings sieht es dann wieder etwas anders aus. So kennt PyQt kein
qmake mehr, wozu auch. Aus
uic wird bei PyQt
pyuic und erstellt nun Pythoncode, der
QUiLoader wird als eigenes Modul
uic vorgehalten. Die Unterschiede von Qt zu PyQt sind in der Riverbank-Dokumentation erschöpfend erläutert, für alles andere kann ich Dir nur die offizielle Qt-API-Dokumentation empfehlen und hierfür ist mitunter ein minimales Verständnis von C++ von Nöten (welche Du aber aufgrund der Einfachheit der Beispiele mit Deinen C-Kenntnissen auf Anhieb lesen können dürftest)
Für grundlegende paradigmatische Fragen (Wie löst man das jetzt elegant in PyQt?) ist, wie gesagt, das Buch von Mark Summerfield hilfreich. Und bei einer konkreten Fragestellung, welche ich in Deinem Ausgangsbeitrag irgendwie vermisse, natürlich dieses Forum.
Das war jetzt hoffentlich nicht zuviel alter Wein in neuen Schläuchen, wenn ja, dann ignoriere den Beitrag einfach...