Changing states of widgets more than once in one function call?

[l-o-u-i-s-g]

example:
In my app I have a button, the on_press calls the function test_ssh
the progress bar is set to max=None

the function test_ssh looks something like this.

def test_ssh(self):
    self.root.ssh_out.value = "Testing SSH ..." 
    self.root.progress.start()

    ......
    code here that takes a while to run and test the ssh connection
    .......

    self.root.progress.stop()
    self.root.ssh_out.value = test_result

in this example the state of the widgets are only modified once the function is done executing so the progress bar is never shown running and the user is never shown the text "Testing SSH..."

I looked at the code in the ProgressBarApp in the examples but the start and stop are called by the user. Is there a way that I'm not seeing to get the desired effect?

Do I have to open another activity (pop-up window) when the user presses the test_ssh button and have the progress bar started in this new activity and a text displayed once its ended?

[freakboy3742]

This is something that is covered by step 8 of the BeeWare tutorial; although in this case, the connection might not be apparent.

If you have a handler method that is making changes to the GUI, there's no guarantee that those changes will manifest in a visual way until at least one iteration of the event loop has occurred. This is because the event loop is what does the redrawing - so until you (implicitly) call redraw, GUI changes aren't guaranteed to be visible. This isn't a 100% guarantee - on some platforms, GUI changes will be visible immediately due to the specifics of how the GUI toolkit is implemented - but as a general rule, it's a good principle to rely on.

For example, if you have a handler that looks something like:

def my_handler(widget, **kwargs):
    widget.text = "Initial text"
    do_busy_work()
    widget.text = "New text"

the "Initial text" label isn't guaranteed to be displayed. Further - if do_busy_work() takes a non-trivial amount of time to complete, you're going to see beachballs/lockups in your app, because you're not giving the app the opportunity to redraw and process GUI events.

If you want your GUI to update "mid handler", you need to release control to the event loop. You can do this in Toga by making your handler asynchronous, and awaiting something (anything - a 0 second sleep is an easy default):

async def my_handler(widget, **kwargs):
    widget.text = "Initial text"
    await asyncio.sleep(0)
    do_busy_work()
    widget.text = "Final text"

The "sleep 0" releases control to the event loop for one iteration, allowing a redraw to occur; you'll see the "initial text" label displayed, then the work will be done, then the label will be updated to "Final text".

However, this won't fix the lockup of the app while the "busy work" is done; realistically, do_busy_work() also needs to be asynchronous. If you're doing network activity, for example, that means using an async-compatible networking library. This would also remove the need to do the sleep 0, as any await call will release control to the event loop. The tutorial contains an example of a library that can be used for asynchronous HTTP work; if you need lower level sockets, there are other libraries that are available.

[l-o-u-i-s-g]

Thanks for the fast reply!

I had tried making it async earlier today but couldn' t figure out how to make paramiko async and just lost that frame of thought.
The await with the sleep is a good little trick but I had to make the sleep greater than 0, something like 0.05 for the text to change.
For the progress bar we can clearly see how this freezes the app since the progress bar starts but freezes after the asyncio.sleep delay.
I found another library "asyncssh" I will be going that route...