You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
await get_input() doesn't enable testing since the caller has no access to the window or other resources. Presently the focus has been on doing window = create_window(); await window.wait(). Consider offering window = await nursery.start(create_window).
The text was updated successfully, but these errors were encountered:
A common need is to create a window and then wait for it to be shown. With the existing approach here in QTrio we create the window, connect to it's shown signal (which has to be added), start the window, then wait for the shown signal. With the proposed nursery.start() usage this all collapses down to window = await nursery.start(create_window). create_window() in this case will create the window, show it, then return that object through the task_status that nursery.start() provides and we assign it to window. It is good to still be able to access all the separate pieces but helpful to not _have_ to deal with them every time. This retains testability since you do launch the window in a separate task and also get the window object so you can poke at it programmatically. This was approach suggested by one of the Trio dev's when I described the window as being like a server that we need to start and then let the user interact with, just as they would with a webserver you might run except the server input is clicks
and keypresses and resize events etc instead of http.
await get_input()
doesn't enable testing since the caller has no access to the window or other resources. Presently the focus has been on doingwindow = create_window(); await window.wait()
. Consider offeringwindow = await nursery.start(create_window)
.The text was updated successfully, but these errors were encountered: