Das deutsche Python-Forum

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?

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

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

burli hat geschrieben:die *.ui files mit einem kleinen Program in *py Files zu verwandeln ist nicht wirklich ein Umweg.

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.

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.

*kopfschmerzen* GTK+, wx, qt bla bla... das macht mich so schlau wie vorher

Leonidas hat geschrieben:

burli hat geschrieben:die *.ui files mit einem kleinen Program in *py Files zu verwandeln ist nicht wirklich ein Umweg.

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.

Man kann die *.ui Files auch direkt einbinden. Frag mich jetzt aber nicht wie
Andererseits hat man dann das UI direkt als Python Code vorliegen. Dürfte schneller geladen sein

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

Wo liegt Dein Problem? Schau Dir die einzelnen Libs an und probiere etwas herum. Dann wirst Du schon sehen, welche Dir am besten gefällt!

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?

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?

Für wxPython gibt es wxGlade (extra downloaden, ist ein Sourceforge projekt) und den "Resource Editor", der mit der Distribution mitgeliefert wird.
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.

Threadsafe eher nicht, aber das ist AFAIK keines der gängigen Toolkits.

Qt bringt eigene Thread Funktionen mit die man in Verbindung mit Qt auch bevorzugt nutzen sollte

http://doc.trolltech.com/4.3/threads.html

burli hat geschrieben:Qt bringt eigene Thread Funktionen mit die man in Verbindung mit Qt auch bevorzugt nutzen sollte

Tkinter, wxPython und PyGTK haben für den Programme mit mehreren Threads Lösungen, also das ist nicht direkt ein Alleinstellungsmerkmal.

Leonidas hat geschrieben:

burli hat geschrieben:Qt bringt eigene Thread Funktionen mit die man in Verbindung mit Qt auch bevorzugt nutzen sollte

Tkinter, wxPython und PyGTK haben für den Programme mit mehreren Threads Lösungen, also das ist nicht direkt ein Alleinstellungsmerkmal.

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ß.

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

burli hat geschrieben:entweder Python Threads oder direkt das Betriebssystem verwendet

Python-Threads sind OS-Threads. Im Gegensatz zu Ruby 1.8, wo das vom Interpreter verwaltete Green-Threads sind.

QThread nutzt ebenfalls Betriebssystemthreads.

lunar hat geschrieben:QThread nutzt ebenfalls Betriebssystemthreads.

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).

burli hat geschrieben:

lunar hat geschrieben:QThread nutzt ebenfalls Betriebssystemthreads.

Bleibt ihm letztendlich nichts anderes übrig.

Wieso?

Ich wollte lediglich darauf hinweisen das Qt dafür eben eigene Funktionen mitbringt die man auch nutzen sollte.

ack.

lunar hat geschrieben:

burli hat geschrieben:

lunar hat geschrieben:QThread nutzt ebenfalls Betriebssystemthreads.

Bleibt ihm letztendlich nichts anderes übrig.

Wieso?

Naja, wenn's "vernünftig" sein soll...
Alles andere sind IMHO nur Krücken

burli hat geschrieben:

lunar hat geschrieben:

burli hat geschrieben:

lunar hat geschrieben:QThread nutzt ebenfalls Betriebssystemthreads.

Bleibt ihm letztendlich nichts anderes übrig.

Wieso?

Naja, wenn's "vernünftig" sein soll...

Wieso sind leichtgewichtige Threads denn unvernünftig?

Alles andere sind IMHO nur Krücken

Diese Krücken sind aber oftmals schneller als "echte" Threads, da zu ihrer Verwaltung keine Kontextwechsel nötig sind.