Qt4 mit Python beleben

Python und das Qt-Toolkit, erstellen von GUIs mittels des Qt-Designers.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

3ff hat geschrieben: Es spielt auch keine Rolle, mit welchen "Sprachkenntnissen" man an Qt rangeht, denn die Pythonbibliothek kann man ohnehin nicht gebrauchen.
Wie genau meinst Du das?
Die Qt-Programme, die py4uic erzeugt, sind an Python "angelehnt".
Ich würde hier doch noch mal das uic-Modul erwähnen - das spart einem den statischen Übersetzer... (wurde hier im Forum schon oft diskutiert; und in der gescholtenen PyQt-Doku steht das aber beschrieben ;-) )
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
3ff
User
Beiträge: 191
Registriert: Dienstag 22. Dezember 2009, 12:54
Wohnort: Odenwald Sued-Hessen

@Hyperion
bitte geb mit noch etwas Zeit, ich hab heute 1 Dampfbügeleisen repariert und jetzt stehen
noch andere Sachen auf dem Zettel.
Ich hab auch 1 schönes Beispiel gefunden wie riverbankcomputing in Python dokumentiert.
Guude
Fritz :?
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@3ff
Das Herzstück von Qt ist die GUI-Bibliothek, wobei die Qt-Macher die Bibliothek in der Vergangnenheit um grundlegende "jeden Tag"-Programmieranforderungen erweitert haben (Socketprogrammierung, Threads, neuerdings Zustandsautomat etc.). Damit mausert sich Qt eher zu einem Schweizer-Taschenmesser-Ansatz, was gerade unter C++ einiges an Programmieraufwand abnimmt.
Dinge wie Designer (mit Programmgenerator), Ressourcen- und Sprachverwaltung sind eher als tolle Zusatzfeatures zu verstehen (als Teil der eigenen Buildumgebung in C++) und setzen größtenteils auf den von der Bibliothek zur Verfügung gestellten Methoden auf. Du könntest das auch explizit im Quelltext selbst vornehmen (zumindest den ui-Teil hartkodiert).
In Python sind manche der Taschenmesserfunktionen und build-tools unsinnig (weil pythoneigene Abstraktion verfügbar usw.) und daher anders bis gar nicht verfügbar. Im Übrigen erstellt pyuic echten Pythoncode und ist nicht nur an Python angelehnt.

zu den Sprachkenntnissen:
Qt ist ein C++ Kind und entsprechend sind die Dokumentation und die Bsp. seitens Qt für C++ verfasst. Riverbank hat sich nicht die Mühe gemacht, jeden kleinen Schnipsel nach Python zu übersetzen. Ich halte es hier mit BlackJack und bin der Meinung, dass diese Transferleistung der Programmierer erbringen können sollte (Zumal die Minibsp. meist nur geringe Syntaxunterschiede ausmachen).
Als Kind von C++ folgt Qt natürlich dem OOP-Konzept, wer sinnvoll mit Qt programmieren will, sollte grundlegende Praktiken von OOP kennen. Das gilt schon für Python an sich.

zur Organisation:
Für größere Projekte ist einfaches Drauflos-Programmieren immer ein denkbar schlechter Ansatz. Auch für den agilen Entwicklungsansatz ist bei Einsatz mehrerer Entwickler eine Art Superdokumentation nötig, damit eine hohe Orthogonalität erreicht wird und nicht das Projekt in seine Einzelteile zerfällt. Das ist aber eine klassische Frage der Softwareentwicklung und kein Qt-spezifisches Problem.
philistion
User
Beiträge: 108
Registriert: Sonntag 7. Februar 2010, 14:16

jerch hat geschrieben:Für größere Projekte ist einfaches Drauflos-Programmieren immer ein denkbar schlechter Ansatz.
Abgesehen davon führt der Designer allein selten zum Ziel.

@3ff
Die Diskussion über CPP-Kenntnisse bezog sich auch nicht auf die Bedienung der bunten Klick-Gui QtDesigner, die wohl jeder wie du sagst per "Learning-By-Doing" hinbekommt, sondern auf das Schreiben von Python-Code für Qt-Anwendungen.

Ich würde dir übrigens auch empfehlen, die Docs von Riverbankcomputing zu konsultieren, dort ist "nahezu alles" (oder sagen wir "der Großteil") Python-gerecht dokumentiert. Wenn man Glück hat sogar teilweise mit Beispielen :)
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@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...
Antworten