As other posters said, nothing about the functionality you mention is something that needs threads (and even more importantly, threads will definitely not make the functionality easier to implement - they rarely do in any case). In particular, you said you want: "the possibility to easily switch one part of my GUI on or off by instantiating resp. deleting an object of the responsible class" - and that's very easily done in a single thread by maintaining a list of active objects with update calls that is iterated in the way James suggested... and even if you used threads, you'd probably still need to keep and maintain and iterate that list in some fashion to make sure the threads know where they are supposed to draw in your window (someone would need to allocate the shared gui space, threads or not).
However, I think the real factor that will determine whether threads will be worth the trouble they bring will be performance, which is something you haven't talked about at all For instance, if you have a task to accomplish that takes multiple seconds, or you have a task that takes near a second, but happens frequently, you'll find that doing that task in your user interface thread makes for a very unresponsive and unusable GUI. Because of this, one very common and useful situation for threads is to make your main thread completely responsible for everything about the GUI, and then spawn threads for long running tasks which post events to the main thread when the gui needs to do stuff, so that the window is always responsive to clicks and stuff. In that model, it's actually desirable to not let be doing any event handling or rendering in the task threads, so that limitation is no biggie. On 8/3/06, Lars Friedrich <[EMAIL PROTECTED]> wrote:
I need to get frames from a camera and display them on the screen. At the same time, I have to do some other stuff. I wrote a "Camera"-class which has a "getFrame" method, returning a frame in a numpy-array. Now I also have a "CamWindow"-Class (that inherits from "Thread") which will know which camera's frames are to be displayed. It works like this:
If your "getFrame" method is slow, like more than double digit milliseconds or that, then threads may be interesting for you... and if you do use the threads, you should make the threads post events to the pygame queue, and you can easily "delete" threads by turning "while 1" loops until "while self.keep_running" where keep_running is a simple boolean flag that gets cleared before the thread is started, and gets set by some other thread also, Is it possible you want multiple processes? If you want multiple windows with pygame (as opposed to drawing multiple things in the same window) then you'd need multiple process. Also, how will the tasks you originally thought of happening in different threads interact with each other? If the interaction is pretty simple/infrequent the
