On 29.05.2018 23:20, Mark Roseman wrote:
> Mark Roseman <mark@markroseman.com> added the comment:
>
> Ivan, thanks for making a good first pass of this. The thread section still feels a lot like 'fighting' with the model. Do you mind if I take a crack at it? Won't get to it for a few days, but in case you have any stuff you're in the middle of.
>
> I should clarify too that Tk apps almost universally do use a blocking event loop (i.e. 'vwait forever' at the end of a script). Application-level event handlers are supposed to respond quickly so control goes back to the event loop.
>
> It's when control doesn't return there that things like the 'update idletasks' hacks are needed. In practice, I've noticed that's what seems to trip people up when they first start, as they try to emulate the flow of their non-GUI code, which frequently blocks. Far better that the program is restructured so that the event handler completes quickly. It's actually worse than it looks, because you can end up having nested event loops if you start randomly throwing this stuff in. That's conceptually hard for most people and a good source of bugs.
>
I'm pretty much done with the threading section but if you think it 
could use more clarification, sure. You can make a PR against my branch 
to integrate changes (or vice versa).

In line with the aforementioned plan, the "Threading model" section 
needs to tell these things critical to interstanding the module's 
behavior and usage patterns:

* There are two basic GUI execution models (stricty speaking, these are 
event-driven models in general, but no need to go that deep): single 
thread with pumping messages by hand (read: cooperative multitasking), 
and UI thread + worker threads (read: preemptive mulitasking). The 
latter is prevalent now so the reader is more likely to be familiar with it.
* Tcl/Tk implements the former model (which is unusual), Tkinter 
emulates the latter with its own logic (so Tcl/Tk docs won't have info 
on this) but supports the former one as well. (So update() is not a 
"hack" at all, it's just intended for a different use case that doesn't 
come up often.)
* Tkinter calls can and should be made from any threads (this is also 
unusual), but there are user-visible limitations.
* Tcl event loop is shared (another unusual gimmick), which is also 
user-visible.

This section is not the place to showcase concrete usage patterns, 
that's what tutorials are for. But it can make references to relevant 
Tkinter functions as long as this doesn't garble the narration.

I imagine tutorial as a separate page (see the plan how it should be 
linked to), with the following sections, each illustrated with code. 
It's not meant to be an essential part of this ticket because it's of 
lower priority.

* Create initial UI, then run mainloop(). All the rest is done with ui 
commands and events. (a hello world example)
* Start a worker thread for any action that may take more than a 
fraction of a second. Make Tkinter calls from the worker thread to pass 
back info on its progress.
* Collect worker threads and do other cleanup at exit via a cleanup 
function. Call it from both a special exit command, if any, _and_ from 
.protocol("WM_DELETE_WINDOW"). Lengthy/perpetual worker threads' logic 
must be interruptable for this.
* For more complex logic, use the Model-View-Presenter pattern.
* ?Something about exception handling? (Propagating exceptions? Making 
unhandled exceptions visible to the user? I dunno atm)
* An example of using Tcl's execution model, i.e. with 
dooneevent()/update()/update_idletasks() instead of mainloop(), like a 
Tcl program would do.