Tk windows in different threads
Eckhard Lehmann
from time to time I read that it is not advisable to use Tk windows in
more than one thread.
Unfortunately, this is what I need :(. One part of a GUI-app should be
updated while the other parts of the GUI are *not blocked* (i.e. a
ttk::treeview updates itself while the user can edit a file in the text
widget nearby at the same time in the same application).
How is the status on Tk and threads? Is it (in theory) possible to
change Tk widgets in a different thread from that where they were
created? I want to create the widgets in the main thread, but
[configure] it's options / call commands on it in a second thread. When
widgets are deleted, this is done in the same thread where they were
created, never in a different thread.
Or is there another way to get this non-blocking behaviour, maybe
without threads?
TIA,
Eckhard
Michael Schlenker
I don't really understand what you want to achieve, but why not just
thread::send -async the commands you want to have in effect and let Tk
run just from one thread?
Michael
Eckhard Lehmann
Michael Schlenker wrote:
> I don't really understand what you want to achieve, but why not just
> thread::send -async the commands you want to have in effect and let Tk
> run just from one thread?
Because the commands involve reconfiguration and subcommand invocations
on Tk windows (which exist, of course, in the main thread but not in
the others). So I would need exactly those Tk windows in the other
thread(s), to be able to thread::send the commands I want to send.
Example:
...
button .b -text hello
set tid [thread::create -preserved]
thread::send -async $tid [list .b configure -text bye] res
...
And .b has the -text attribute set to "bye" after that. Of course, the
real code is much more complicated and time consuming...
I can imagine that the widget data can be set as thread shared data on
C level, so that it is accessible in different threads, but I don't
know what side effects this would have. That's why I ask...
Eckhard