Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
On 29.05.2018 23:20, Mark Roseman wrote:
> Mark Roseman <m...@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.
----------
nosy: +__Vano
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33479>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
