Ich versuche gerade Tetris in python zu programmieren und es ist mir auch schon fast alles gelungen, doch bei mir ist ein Problem aufgetaucht!
Ich weis nicht wie ich die Anweisung geben kann das pro eine bestimmte Zeit etwas geschehen soll (hier das runterbewegen der Figuren)
Kann mir jem. raueshelfen? [/code]
Fortlaufen eines Programms???
ein zeitgesteuerter thread?
Diese Klasse ruft dann alle Zentelsekunde die Funktion mache_etwas auf.
Start der Schleife:
Ich hoffe, dass ich dich richtig verstanden habe
Code: Alles auswählen
import threading, time
class T (threading.Thread):
def run(self):
while 1:
mache_etwas()
time.sleep(0.1)
Start der Schleife:
Code: Alles auswählen
t = T()
t.start()
Code: Alles auswählen
import threading, time
class T (threading.Thread):
def __init__(self):
threading.__init__(self)
self._paused = 0
def run(self):
while 1:
if (self._paused): continue
mache_etwas()
time.sleep(0.1)
und dann kannste mit
Code: Alles auswählen
t._paused = 1
Code: Alles auswählen
t._paused = 0
Code: Alles auswählen
t = T()
t.start()
t._paused = 1 # pause
t._paused = 0 # weiter
Dies ist eine ganz üble Warteschleife, die 100% der Rechnenleistung frist und die es zu vermeiden gilt. Es wird auch in Python bessere Wege geben, einen Thread anzuhalten, etwa indem man auf eine Semaphore wartet.Birne94 hat geschrieben:Code: Alles auswählen
while 1: if (self._paused): continue
Bei der GUI-Programmierung sollte man lieber auf Threads verzichten, denn fast kein GUI-Rahmenwerk ist threadsafe. Üblicherweise - ich kenne mich mit Python-GUIs leider nicht aus - kann man einen Zeitgeber benutzen, über den man sich einmalig oder periodisch aufrufen kann.
Frohe Weihnachten
@sma Deswegen ist ja noch das time.sleep mit drin Trotzdem unschön gerade bei GUI Toolkits sollte das mit Events machbar sein, bei PyQt4 ist dass aufjedenfall kein Problem im Thread auf ein Event zu reagieren.
@DasIch: wenn ``bool(self._paused)`` True ergibt, dann ist da kein sleep drin und es frisst alle Rechenleistung. Außerdem braucht man für periodische Aufrufe eigentlich keine Threads, weil das wirklich jedes Toolkit können müsste.
"Der Dumme erwartet viel. Der Denkende sagt wenig." ("Herr Keuner" -- Bertolt Brecht)
Code: Alles auswählen
import threading, time
class T (threading.Thread):
def __init__(self):
threading.__init__(self)
self._paused = 0
def run(self):
while 1:
if (self._paused): continue
time.sleep(0.1)
mache_etwas()
und dass es nicht das Beste ist, ist mir auch klar
Code: Alles auswählen
import threading, time
class T (threading.Thread):
def __init__(self):
threading.__init__(self)
self._paused = 0
def run(self):
while 1:
time.sleep(0.1)
if (not self._paused):
mache_etwas()
Ich denke, du verwechselt hier Signale mit Ereignissen. Ereignisse, die vom Rahmenwerk (ich wollte dieses Wort auch mal verwenden, sma ) ausgelöst werden, sind keinesfalls threadsicher. Konkret bedeutet das, dass ein PaintEvent z.B. nicht threadübergreifend funktioniert. Es kann daher einzig und allein der Hauptthread auf ein Widget zeichnen. De fakto ist Qt4 genauso wenig threadsicher wie jedes andere GUI-Toolkit. Das ist technisch auch völlig sinnvoll, da paralleles Zeichnen weitreichende Synchronisationsprobleme mit sich bringen würde. Was passiert z.B. wenn zwei Threads parallel auf dieselbe Fläche zeichnen? Das ließe sich nur über komplexes Locking lösen, mit entsprechend negativen Auswirkungen auf die Performance.DasIch hat geschrieben:@sma Deswegen ist ja noch das time.sleep mit drin Trotzdem unschön gerade bei GUI Toolkits sollte das mit Events machbar sein, bei PyQt4 ist dass aufjedenfall kein Problem im Thread auf ein Event zu reagieren.
Signale und Slots in Qt4 dagegen sind threadsicher (aber eben auch etwas anderes als Ereignisse, deswegen heißen sie ja auch anders ). Allerdings laufen threadübergreifende Verbindungen zwischen Signalen und Slots über eine Queue, Sender und Empfänger leben also in verschiedenen Threads. Wenn z.B. ein QThread ein Signal aussendet, welches mit QLabel.setText verbunden ist (z.B. für eine Statusanzeige), dann läuft QLabel.setText nicht im QThread, sondern im Hauptthread des Programms (der die GUI erzeugt hat) ab.
Im Übrigen wäre ein Thread zur Lösung des gestellten Problems in Qt4 völlig deplaziert, QtCore.QTimer existiert.