Hallo,
ich möchte jetzt von tkinter zu QT wechseln und frage mich, ob es Gründe gibt, Qt Designer nicht zu verwenden. Außerdem bringt Qt zahlreiche Klassen für alles mögliche mit (Netzwerk etc.). Wie handhabt man das in der Praxis, wenn ähnliche Funktionalitäten bereits von Python selbst bereitgestellt werden? Qt oder natives Python?
Vielen Dank.
QT von Hand coden oder Qt Designer
Es hat Vorteile Qt Klassen zu benutzen weil die durch ihr Signal Slot pattern dann einheitlich funktionieren, und auch den Qt mainloop kennen.
Designer würde ich empfehlen, da man bei ordentlicher benahmung der Widgets damit sauber Code von Layout trennt. Und letzteres ändert sich schon mal schnell.
Designer würde ich empfehlen, da man bei ordentlicher benahmung der Widgets damit sauber Code von Layout trennt. Und letzteres ändert sich schon mal schnell.
-
__blackjack__
- User
- Beiträge: 13103
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@Grendel: Designer macht IMHO Sinn. Dann wird das Layout der GUI zu einer Datendatei die mit einer grafischen Oberfläche erstellt und bearbeitet werden kann, was sonst oft zu einer ziemlichen Wüste an Code ausartet, bei der man sich oft auch durch's lesen nicht so gut vorstellen kann, wie es am Ende am Bildschirm aussieht.
Bei den Nicht-GUI-Klassen aus dem Qt-Rahmenwerk muss man halt schauen in wie weit sich die Vorteile (Signal/Slot) gegen die Nachteile – also hauptsächlich die Abhängigkeit von Qt – abwiegen lassen.
Ich persönlich würde mich zum Beispiel schwer damit tun die Qt Network Klassen als ”Ersatz” für `requests` zu verwenden, einfach weil ich die API gewohnt bin, und man den Teil dann auch ohne Qt-Abhängigkeit verwenden kann.
Bei den Qt SQL Klassen könnte ich mir das nur bei wirklich ganz simplen CRUD-Anwendungen vorstellen dem einen Vorzug vor SQLAlchemy zu geben.
Die Qt Test Klassen habe ich mir noch gar nicht angeschaut. Ich denke hier wird es auch schwer das py.test was ich verwende zu ersetzen.
Qt Concurrent wird AFAIK in den Python-Bindings gar nicht erst angeboten. Die ganzen Containerdatentypen werden auch nicht angeboten.
Von JSON- und XML-Kram von Qt würde ich die Finger lassen, das gibt's auch in der Python-Standardbibliothek (+ `lxml`) in einer API die deutlich weniger nach statischer Programmiersprache aussieht.
Bei den Nicht-GUI-Klassen aus dem Qt-Rahmenwerk muss man halt schauen in wie weit sich die Vorteile (Signal/Slot) gegen die Nachteile – also hauptsächlich die Abhängigkeit von Qt – abwiegen lassen.
Ich persönlich würde mich zum Beispiel schwer damit tun die Qt Network Klassen als ”Ersatz” für `requests` zu verwenden, einfach weil ich die API gewohnt bin, und man den Teil dann auch ohne Qt-Abhängigkeit verwenden kann.
Bei den Qt SQL Klassen könnte ich mir das nur bei wirklich ganz simplen CRUD-Anwendungen vorstellen dem einen Vorzug vor SQLAlchemy zu geben.
Die Qt Test Klassen habe ich mir noch gar nicht angeschaut. Ich denke hier wird es auch schwer das py.test was ich verwende zu ersetzen.
Qt Concurrent wird AFAIK in den Python-Bindings gar nicht erst angeboten. Die ganzen Containerdatentypen werden auch nicht angeboten.
Von JSON- und XML-Kram von Qt würde ich die Finger lassen, das gibt's auch in der Python-Standardbibliothek (+ `lxml`) in einer API die deutlich weniger nach statischer Programmiersprache aussieht.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman