Hi! That's the general issue of retained GUI's that's powered by some kind of event loop (Qt, VCL, Tcl/Tk and etc.).
Also you shouldn't change (call methods of, or change member values) of GUI elements from other threads than main, that's the fast way to get race condition or/and segfault in retained mode GUI, because main GUI thread can render/change that elements in parallel (concurently) from the main thread. That's definately an error. There's some way to schedule some callback on the main GUI thread in general or signal/slots (Qt) or global mutex acquire (FLTK). Your callback for buttonSave.onClick occupies exclusively event loop till callback finishes. In the same time GUI update is taking place in the same event loop, so your GUI is not updated until event loop gets out of button callback. Hope I explain the issue understandable in some degree. I have no expirience with Nim or NiGui so I might be wrong, take my answer with the grain of salt. In each retained GUI framework there is some way to call event loop scheduling from callback to process pending events (e.g. update GUI). Looks like it's app.processEvents() in NiGui (<https://github.com/simonkrauter/NiGui/blob/master/src/nigui.nim#L472C1-L472C30>) Do note that this design considered as antipattern because if you click again on the button, another instance of callback would be executed concurrently and things gets pretty messy and may lead to segfault if there's some callback-local data that starts changing from all pending callbacks, that schedules in some kind of app.processEvents(). Please take a look at example in NiGui repo: <https://github.com/simonkrauter/NiGui/blob/master/examples/example_15_threading.nim#L31C1-L31C26> IMHO it's better to schedule callback on event loop (GUI main thread) from you worker thread with app.queueMain.
