Thread Problem

[BlackJack]

@prog(r)amer: Ich würde auf die „neue” Art Signale und Slots verbinden umstellen und das `response`-Signal in der `Worker`-Klasse definieren. „Neue” in Anführungsstrichen, weil das eigentlich gar nich mehr so neu ist. Eine Umstellung bringt weniger Schreibarbeit und mehr Typsicherheit, dass heisst Fehler fallen früher auf. Wobei Du selbst für die alte Variante wohl das umständlichste und längste genommen hast, was man da schreiben kann.

Der Quelltext entspricht in der Form nicht ganz dem Style Guide for Python Code (PEP 8). Bei der Namensgebung ist es üblich die gepflogenheiten von GUI-Toolkits zu übernehmen, aber die Einrückung und Leerzeichensetzung kann man auch da vom Guide übernehmen.

``while`` ist keine Funktion, deshalb sollte man es auch nicht so schreiben als wäre es eine. Die Klammern sind in Python an der Stelle sowieso überflüssig.

Der `Worker` wird erstellt und gestartet bevor die GUI aufgesetzt und die Signale verbunden sind. Da können also potentiell Daten verloren gehen.

Wo kommt `s` eigentlich her? Das sieht nach einer globalen Variablen aus, was ziemlich unschön/unsauber wäre.

Letztendlich kann man hier auch ohne eigene Threads auskommen wenn man die Netzwerkklassen von Qt verwendet. `QTcpSocket` hat zum Beispiel ein Signal das
gesendet wird wenn Daten zum Lesen bereit stehen. Es gibt eine Übersicht zu Netzwerkklassen in der Qt-Dokumentation.

[prog(r)amer]

Ja `s` ist eine globale Variable. Wo soll ich `s` denn sonst definieren?
Den Rest hab ich umgestellt.

[BlackJack]

@prog(r)amer: Wenn Objekte auf andere Zugriff haben müssen, dann in der Regel dadurch, dass sie das andere Objekt als Attribut haben oder es beim Methodenaufruf als Argument übergeben bekommen. Also könnte man das der GUI-Klasse bei der Erstellung übergeben und das Objekt gibt es dann an den `Worker` weiter. Oder man übergibt es dem `Worker` und *den* dann der GUI-Klasse. Letztendlich würde ich zusehen Programmlogik und GUI nicht so eng zu vermischen.