os.system Aufruf in einem Thread aufrufen

[piwi]

Hallo,

ich habe folgendes Problemstellung in einer wxPython GUI Anwendung:

Ich möchte über die System-Funktion(os.system(...) das "tftp [Host] put [File]" Kommando aufrufen, um ein Embedded System über TFTP upzudaten.
Wenn ich nun den Update-button drücke, ist die Fensterfunktion außergefecht gesetzt. Wie kann ich das am besten regeln, dass in der Zeit, in der das TFTP Kommando ausgeführt wird, ein Balken angezeigt wird, der immer hin und her läuft, um dem User anzuzeigen, das da gerade ein Update läuft????

Schönen Gruß
Piwi

[HWK]

subprocess.Popen, dann mit poll() schauen, ob das Programm schon fertig ist.
MfG
HWK

[piwi]

Danke für deine Hilfe...

das ist der erste aufruf in meiner OnButtonEvent Routine:

Code: Alles auswählen

proc = subprocess.Popen("tftp " +self.host+ " put
+self.filePickerCtrl1.GetPath())

Wo rufe ich nun am besten die proc.poll() Routine auf???
Soll ich dazu einen timer laufen lassen der den Wert alle 500ms abfragt??

[lunar]

Grundsätzlich musst Du an subprocess.Popen eine Liste übergeben, die jedes Argument in einem eigenen Element enthält.

Ansonsten ist es für diese Zwecke empfehlenswert, die Prozess-Klasse des verwendeten GUI-Toolkits zu verwenden, sofern es eine besitzt.

[Dav1d]

wxPython besitzt eine Prozessklasse wx.Process
Allerdings kann man genauso subprocess verwenden, es sollte zu keinem Fehler kommen (Ich habe die Frage: "Lieber wx.Process anstatt subprocess?" auch schon in #wxPython auf freenode gestellet, an einen Developer)
wxPython bringt auch einen eigenen Timer mit: wx.Timer(self).start(500), alle 500ms wird ein wx.EVT_TIMER gesendet

[lunar]

Fehler gibt es sicherlich nicht, aber möglicherweise ist wxProcess einfacher zu nutzen. Ich kenne wx nicht, insofern kann ich nicht sagen, ob das tatsächlich so ist.

Bei Qt4 beispielsweise bietet QProcess den Vorteil, dass es Signale und Slots unterstützt, und sich in die Ereignisschleife integriert. Man muss also nicht manuell prüfen, ob der Prozess sich beendet hat, oder ob Ausgabe bereit steht, sondern erhält völlig automatisch ein Signal. Das macht die Verwendung von QProcess wesentlich einfacher gegenüber subprocess.

Dann ist auch kein Polling mehr nötig.

[Dav1d]

Oh ja, klar wx.Process, teilt dem "parent" ja per wx.EVT_END_PROCESS mit, wenn der Prozess am Ende ist
AFAIR, ist es das einzigste Event (EVT_END_PROCESS)

[HWK]

einzigste Event

Nicht böse sein: einzige (einzig kann man nicht mehr steigern).
MfG
HWK

[Dav1d]

[piwi]

vielen dank für die vielen Antwort.
Habe es jetzt mit dem wx.Timer gelöst und es funktioniert...
Werde mir auch noch mal die wx.Process Klasse angucken.

Wenn ihr die Wahl hättet zwischen Qt4 und WX für Python, was würdet ihr empfehlen?????

SChönen Gruß
Piwi

[DasIch]

Wenn ihr die Wahl hättet zwischen Qt4 und WX für Python, was würdet ihr empfehlen?????

Wenn man zwei Wahlmöglichkeiten hat und Wx ist eine davon wählt man die andere.

[lunar]

@piwi: Qt4 ist ganz allgemein sehr empfehlenswert. Einen Vergleich mit wxWidgets kann ich allerdings nicht geben.

[gerold]

Wenn ihr die Wahl hättet zwischen Qt4 und WX für Python, was würdet ihr empfehlen?

Hallo piwi!

wxPython und "wxPython in Action"

Einzige Ausnahme: wenn du KDE-Programme schreiben möchtest

mfg
Gerold

[Leonidas]

Wenn ihr die Wahl hättet zwischen Qt4 und WX für Python, was würdet ihr empfehlen?????

Wenn man zwei Wahlmöglichkeiten hat und Wx ist eine davon wählt man die andere.

Exakt. Na vielleicht von Tkinter abgesehen.

[lunar]

@Leonidas und DasIch: Und aus welchen objektiven Gründen sollte man das tun?

[Dav1d]

Frage ich mich auch gerade ...
Ich bin mir sicher, dass ihr beide nicht wxPython und Qt beherrscht um solche Urteile zu fällen

[Leonidas]

Ich bin mir sicher, dass ihr beide nicht wxPython und Qt beherrscht um solche Urteile zu fällen

Also beherrschen würde ich nicht sagen, aber genutzt haben - durchaus.

Meine Gründe gegen wxPython: als ich es genutzt hatte, hatte es keine brauchbare Dokumentation, die API war unangenehm (ne angenehme API hat eigentlich kein größeres Toolkit), es crashte bei mir oft und die Bugs wurden dann immer erst im nächsten Release ausgebessert, wer weiß wann das kam. Zudem gab es keine brauchbaren GUI-Designer, wxGlade ist nur ein trauriger abklatsch von Glade. XRCed schien noch am besten, aber viele Features hat der auch nicht geboten. Zudem ich bei wxWidgets generell in den letzten Jahren keinen nennenswerten Fortschritt sehe, aber das nur so als Argument hinterher.

Meine Gründe für Qt: Trolltech/Nokia entwickeln das Toolkit ständig weiter, mit KDE steht ein "Big-Player" auf dem Desktop hinter Qt, es läuft brauchbar auf Linux/Mac OS X und Windows (falls das für jemanden relevant ist), der Qt Designer ist ziemlich brauchbar. Ich hatte damit auch noch keinerlei Crashes und als ich es mal eine halbe Woche für ne Firma probegefahren habe kam es mir für die Anforderungen (Crossplatform, Funktionsreich, Etabliert) noch am passendsten vor.

[DasIch]

Ich bin mir sicher, dass ihr beide nicht wxPython und Qt beherrscht um solche Urteile zu fällen

Ich hab mit Wx angefangen weil mir da der Windows Support wichtig war und ich von der C++ Dokumentation von Qt abgeschreckt war. Ich hab dann aber doch sehr schnell auf GTK gewechselt und bin mit meinem Umstieg von Gnome auf KDE4 auf Qt umgestiegen.

GTK bietet imho die aus Python Perspektive angenehmste API, ich fand die Dokumentation(nicht die Tutorials) nicht sonderlich zufriendenstellend hab dementsprechend auch nicht viel mit gemacht.

Qt ist gut durchdacht, logisch aufgebaut und hat im Allgemeinen eine angenehme API. Desweiteren hat Qt den Vorteil dass man diese riesige Menge an zusätzlichen Features bekommt so dass man von Netzwerk, Datenbank zu Multimedia Anwendung alles hinbekommt ohne sich erstmal zig mehr oder weniger gut zusammen passende Komponenten zusammen zu stecken.

Wx fühlt sich in Python so an wie die wxPython Homepage aussieht und damit meine ich nicht die .php Endung in der URL. Wer sich einen Überblick verschaffen will und erstmal Bilder gucken geht wird dann gleich damit begrüsst, dass... beeindruckt. Gehen wir weiter zur Dokumentation, die ist zwar jetzt nur eine Link Sammlung auf irgendwelche Stellen der wxwidgets Dokumentation ohne dass auf Unterschiede eingegangen wird und eine mit pydoc generierte API (experimentelle) Dokumentation aber glücklicherweise gibt es noch ein Link zu einem Buch, der ist jetzt Tod aber es gibt ja noch ein Wiki was herhalten kann.

Der versuch viel Dokumentation bereit zu stellen ist ja gut und schön aber irgendwie ist da was schief gelaufen.

Wir haben dann eine Seite mit "Recent Changes" deren letzte Aktualisierung ein Jahr alt ist.

Hätte ich jetzt keinen Blick in das svn *sigh* Repo geworfen hätte ich wahrscheinlich angenommen das Projekt wäre Tod und soweit ich mich erinnern kann hat sich da in den letzten 2 Jahren nicht viel an dem Auftritt geändert. Dass zeigt mir aber auch dass da sicherlich keine Firma hintersteht die die Entwicklung weiter vorrantreibt noch eine engagierte Community wie es bei Qt der Fall ist. Wo soll da der Support herkommen den ich sicherlich beanspruchen werde? Wie sicher ist da die zukünftige Entwicklung?

[gerold]

Hallo!

wxWidgets und damit auch wxPython wird laufend weiterentwickelt. Siehe: http://wx.ibaku.net/changelog/

Dass vor ein paar Jahren noch die Api ein Grauen war, das bestreitet sicher niemand. Aber das hat sich radikal geändert.
Das Buch ist super und ist gleichzeitig die beste Dokumentation die man haben kann. Aber man kann, wenn man will, alles schlecht reden.

mfg
Gerold


PS: Persönliche Meinung: Da ich weiterhin Programme schreiben will, die unter Windows und Linux (Gnome) gleichermaßen gut laufen und aussehen müssen, werde ich auch weiterhin bei wxPython bleiben. Wahrscheinlich habe ich keine Probleme mit wxPython, weil ich das zugehörige Buch gelesen habe.

[lunar]

@Gerold: Plattformunabhängigkeit ist beileibe kein Alleinstellungsmerkmal. Qt4-Programme sehen unter Linux, Windows und Mac OS X auch „gleichermaßen gut“ aus, und passen sich soweit als möglich den Gepflogenheiten der jeweiligen Plattform an, bis hin zur Anordnung der Standard-Knöpfe in Dialogen. Unter Linux unterscheidet Qt sogar zwischen KDE und Gnome.

Zu wxPython kann ich nichts sagen. Ich bin wxWidgets nur C++ ein paar mal peripher begegnet, und da gab es jedes Mal Kleinigkeiten, die mich störten.

Beispiel "wxTextInputStream": Da sagt die Dokumentation, man solle vor dem Einlesen auf EOF prüfen. Es gibt dafür aber keine Methode in wxTextInputStream. Um mit wxTextInputStream zu lesen, muss man also immer auch auf den darunter liegenden wxInputStream zugreifen, um wxInputStream::Eof() aufrufen zu können. Das ist nicht gerade saubere Kapselung.

Beispiel "wxExecute": Diese Funktion nimmt wie "exec()" "char**" für das Kommando entgegen, also ein Array von Zeigern auf Zeiger auf Zeichen, abgeschlossen mit einem Nullzeiger. Das ist C, nicht C++, solche Typen haben in einem C++-Toolkit nichts zu suchen. Eine echte Liste wäre an dieser Stelle die richtige Wahl (in diesem Fall wxList<wxString>).

Wie gesagt, nur Kleinigkeiten, aber sie zeigen zumindest, dass es den Entwicklern an diesen Stellen an Sorgfalt fehlte, und ich bin geneigt, von der fehlenden Sorgfalt im Detail auf das gesamte Toolkit zu schließen.