> you disable every single button that allows the user to do something else before the previous operation completes.
Wow you mean the whole program becomes unresponsive? Crazy!
To address your main point, yes, scrolling, hover, etc can continue to work. But now you genuinely have two things your program is doing at once, and these must be coordinated.
A gui framework typically handles this, with a separate thread (or separate OS process). So your thread that responds to events can block while the render/refresh continues doing its thing.
With this design the problem goes away. Instead of writing code that disables the ui, issues a callback, waits to respond, you just literally write:
If (!file.delete()) {
Showerror()
}
This is the kind of code you can read, and put breakpoints on.
> Wow you mean the whole program becomes unresponsive? Crazy!
Yes a normal single threaded GUI normally becomes unresponsive if the user invokes blocking IO on the main (UI) thread. By "unresponsive" in this context I mean "does not process messages the message queue".
That the user can't e.g. perform a certain operation is in this context not the same kind of "unresponsive". It responds (it could even tell him that he can't do it, or why he can't). It would be unresponsive if it gave the appearance that he could do something, but when he tries to, the UI doesn't respond and start the operation he requests.
> Instead of writing code that disables the ui, issues a callback, waits to respond, you just literally write: If (!file.delete()) { Showerror() }
That's typically how I'd write code regardless of whether it's explicitly async. "Disabling everything" usually isn't necessary, what you disable is of course the operations thare logically forbidden to perfom until the first operation completes. In a perfect world you don't have those. But often, you do.
Wow you mean the whole program becomes unresponsive? Crazy!
To address your main point, yes, scrolling, hover, etc can continue to work. But now you genuinely have two things your program is doing at once, and these must be coordinated.
A gui framework typically handles this, with a separate thread (or separate OS process). So your thread that responds to events can block while the render/refresh continues doing its thing.
With this design the problem goes away. Instead of writing code that disables the ui, issues a callback, waits to respond, you just literally write:
If (!file.delete()) { Showerror() }
This is the kind of code you can read, and put breakpoints on.