hallo,
ich kann mich nicht zwischen pyqt und wxpython entscheiden. was ich gerne möchte wäre ein gui designer, allerdings lese ich das bei pyqt das z.b. nur unter umwege möglich ist und auch nicht wirklich so toll sein soll. gibts was für wxpython?
gui designer fuer wxpython, qt usw?
Für einen UI-Designer schau dir mal auf Seiten von QT QT-Designer an und für WX gibts wxGlade. Nun. ich werfe mal kurz meinen Favoriten GTK+ rein, für den gibts mit Glade ebenso einen wunderbaren Designer :=)
Die Auswahl ist groß, und keiner kann dir sagen, nimm das, nimm das. Du musst es einfach ausprobiert haben.
MfG EnTeQuAk
Die Auswahl ist groß, und keiner kann dir sagen, nimm das, nimm das. Du musst es einfach ausprobiert haben.
MfG EnTeQuAk
Umwege? Nicht wirklich toll? Kann ich nicht unterschreiben. Die Implementierung von PyQt ist durchaus gelungen und die *.ui files mit einem kleinen Program in *py Files zu verwandeln ist nicht wirklich ein Umweg. Wenn du Eric4 verwendest ist das nur ein Klick weit entfernt
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Doch, wenn man die Möglichkeit hat die Interface-Dateien direkt zu nutzen wie das in Glade und Gazpacho schon seit langem möglich ist dann fühlt sich Codegeneration wie eine Krücke an.burli hat geschrieben:die *.ui files mit einem kleinen Program in *py Files zu verwandeln ist nicht wirklich ein Umweg.
Andererseits ist der Qt-Designer ein ziemlich gelungenes Tool. Die GTK-Alternativen auch. Unter wxWidgets siehts etwas rar aus, XRCed hat mir noch am ehesten gefallen - aber es genießt eben nicht so einen zentralen Status wie Qt-Designer oder Glade.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Man kann die *.ui Files auch direkt einbinden. Frag mich jetzt aber nicht wieLeonidas hat geschrieben:Doch, wenn man die Möglichkeit hat die Interface-Dateien direkt zu nutzen wie das in Glade und Gazpacho schon seit langem möglich ist dann fühlt sich Codegeneration wie eine Krücke an.burli hat geschrieben:die *.ui files mit einem kleinen Program in *py Files zu verwandeln ist nicht wirklich ein Umweg.
Andererseits hat man dann das UI direkt als Python Code vorliegen. Dürfte schneller geladen sein
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich würde dir sowieso nicht raten nach dem GUI-Designer zu gehen. Wenn du die in frage kommenden Toolkits ausgewählt hast dann nimm dir einfach ein kleines Projekt vor und ziehe das einfach mit beiden Toolkits durch. Danach wirst du sehen, was dir eher zusagt.
Die Leute (mich mit eingeschlossen) hier quatschen sowieso zu viel über Toolkits
Die Leute (mich mit eingeschlossen) hier quatschen sowieso zu viel über Toolkits
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Für wxPython gibt es wxGlade (extra downloaden, ist ein Sourceforge projekt) und den "Resource Editor", der mit der Distribution mitgeliefert wird.Filb hat geschrieben:naja ich werde wxpython ausprobieren, frage mich allerdings ob es threadsafe ist und wird wxpython eigentlich offiziel von wxwidgets untersützt oder sind es einfach nur die bindings?
Empfehlen kann ich selber nichts, da ich mich mit beiden zuwenig beschäftigt habe. XRC (Resource Editor) dürfte ganz gut sein.
"Threadsafe": Weiß nicht genau was du meinst, ich denke aber schon.
Von wxWidgets wird wxPython selbst (glaube ich) nicht aktiv unterstützt.
Die "Bindings" (und natürlich die vielen Erweiterungen, die wxPython selbst noch liefert), werden jedoch massiv von Robin Dunn selbst unterstützt.
Qt bringt eigene Thread Funktionen mit die man in Verbindung mit Qt auch bevorzugt nutzen sollte
http://doc.trolltech.com/4.3/threads.html
http://doc.trolltech.com/4.3/threads.html
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Tkinter, wxPython und PyGTK haben für den Programme mit mehreren Threads Lösungen, also das ist nicht direkt ein Alleinstellungsmerkmal.burli hat geschrieben:Qt bringt eigene Thread Funktionen mit die man in Verbindung mit Qt auch bevorzugt nutzen sollte
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Es wäre schlecht wenn man damit keine Treads verwenden könnte. GUIs ohne Threads machen keinen Spaß. Ich kann aber nur das weitergeben was ich weiß.Leonidas hat geschrieben:Tkinter, wxPython und PyGTK haben für den Programme mit mehreren Threads Lösungen, also das ist nicht direkt ein Alleinstellungsmerkmal.burli hat geschrieben:Qt bringt eigene Thread Funktionen mit die man in Verbindung mit Qt auch bevorzugt nutzen sollte
Der Unterschied zwischen Qt und dem Rest ist aber denke ich das Qt die Threads selbst verwaltet während der Rest entweder Python Threads oder direkt das Betriebssystem verwendet
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Python-Threads sind OS-Threads. Im Gegensatz zu Ruby 1.8, wo das vom Interpreter verwaltete Green-Threads sind.burli hat geschrieben:entweder Python Threads oder direkt das Betriebssystem verwendet
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Bleibt ihm letztendlich nichts anderes übrig. Ich wollte lediglich darauf hinweisen das Qt dafür eben eigene Funktionen mitbringt die man auch nutzen sollte. Soweit ich weiß bietet GTK und wxWidgets nichts vergleichbares (innerhalb des Toolkits).lunar hat geschrieben:QThread nutzt ebenfalls Betriebssystemthreads.
Wieso?burli hat geschrieben:Bleibt ihm letztendlich nichts anderes übrig.lunar hat geschrieben:QThread nutzt ebenfalls Betriebssystemthreads.
ack.Ich wollte lediglich darauf hinweisen das Qt dafür eben eigene Funktionen mitbringt die man auch nutzen sollte.
Naja, wenn's "vernünftig" sein soll...lunar hat geschrieben:Wieso?burli hat geschrieben:Bleibt ihm letztendlich nichts anderes übrig.lunar hat geschrieben:QThread nutzt ebenfalls Betriebssystemthreads.
Alles andere sind IMHO nur Krücken
Wieso sind leichtgewichtige Threads denn unvernünftig?burli hat geschrieben:Naja, wenn's "vernünftig" sein soll...lunar hat geschrieben:Wieso?burli hat geschrieben:Bleibt ihm letztendlich nichts anderes übrig.lunar hat geschrieben:QThread nutzt ebenfalls Betriebssystemthreads.
Diese Krücken sind aber oftmals schneller als "echte" Threads, da zu ihrer Verwaltung keine Kontextwechsel nötig sind.Alles andere sind IMHO nur Krücken