stas poritskiy <stascr...@gmail.com> writes: >> I am working on integration of multiple GUI (Tkinter) elements, such >> a progress bar, label update, etc, and throughout my research i >> discovered that i need to have Threading modules used to distribute >> the calls for GUI update and processing of my main App.
In general your GUI should be in your main process/thread. For example your program doesn't run on Mac OS X because you cannot run the GUI in another process or thread. Now if your GUI actions are starting some actions that last more than a few tenths of a second, you should run these actions in another thread or process (usually a thread will work), otherwise the GUI becomes unresponsive. If you want to exchange some information between the GUI and that thread/process you can use a Queue object, or just give the information from the GUI at the start of the thread. >> My Application is broken into multiple Classes(modules), and i wanted >> to hear your thought on the best practices to implement the Threading >> model. The structure of you modules isn't good. There are circular imports, and that is a sign the the design needs to be simplified: multiProcessLauncher imports gui. gui imports multiProcessLauncher. The latter import isn't necessary. Instead of import multiProcessLauncher processor = multiProcessLauncher name = processor.multiprocessing.current_process().name you can just use: import multiprocessing name = multiprocessing.current_process().name My advice would be to just do the GUI in the main module, and if the Action needs more time, the create a new Thread or Process in the Action class. -- Piet van Oostrum <p...@vanoostrum.org> WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
